ETSITS124 237V8.1.0 



(2009-03) 



Technical Specification 



Universal Mobile Telecommunications System (UMTS); 

LTE; 
IP Multimedia Subsystem (IMS) Service Continuity; 

Stage 3 
(3GPP TS 24.237 version 8.1 .0 Release 8) 



JtSiP 





3GPP TS 24.237 version 8.1 .0 Release 8 1 ETSI TS 1 24 237 V8.1 .0 (2009-03) 



Reference 



RTS/TSGC-01 24237V81 
Keywords 



LTE, UMTS 



ETSI 

650 Route des Lucioles 
F-06921 Sophia Antipolis Cedex - FRANCE 

Tel. : +33 4 92 94 42 00 Fax: +33 4 93 65 47 1 6 

Siret N ° 348 623 562 0001 7 - NAF 742 C 
Association a but non lucratif enregistree a la 
Sous-Prefecture de Grasse (06) N° 7803/88 



Important notice 



Individual copies of the present document can be downloaded from: 
http://www.etsi.orq 

The present document may be made available in more than one electronic version or in print. In any case of existing or 

perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). 

In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive 

within ETSI Secretariat. 

Users of the present document should be aware that the document may be subject to revision or change of status. 

Information on the current status of this and other ETSI documents is available at 

http://portal.etsi.orq/tb/status/status.asp 

If you find errors in the present document, please send your comment to one of the following services: 

http://portal.etsi.orq/chaircor/ETSI support.asp 

Copyright Notification 

No part may be reproduced except as authorized by written permission. 
The copyright and the foregoing restriction extend to reproduction in all media. 

© European Telecommunications Standards Institute 2009. 
All rights reserved. 

DECT™, PLUGTESTS™, UMTS™, TIPHON™, the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered 

for the benefit of its Members. 
2QppTM |g g jracle Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. 

LTE™ is a Trade Mark of ETSI currently being registered 

for the benefit of its Members and of the 3GPP Organizational Partners. 

GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association. 



ETSI 



3GPP TS 24.237 version 8.1 .0 Release 8 2 ETSI TS 1 24 237 V8.1 .0 (2009-03) 



Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). 

The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or 
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. 

The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under 
http://webapp.etsi.org/kev/quervform.asp . 



ETSI 



3GPP TS 24.237 version 8.1 .0 Release 8 3 ETSI TS 1 24 237 V8.1 .0 (2009-03) 



Contents 



Intellectual Property Rights 2 

Foreword 2 

Foreword 6 

1 Scope 7 

2 References 7 

3 Definitions and abbreviations 8 

3.1 Definitions 8 

3.2 Abbreviations 8 

4 Overview of IP Multimedia (IM) Core Network (CN) subsystem Service Continuity 9 

4.1 General 9 

4.2 Underlying network capabilities 9 

4.3 URI and address assignments 9 



5 Functional entities 10 

5.1 Introduction 10 

5.2 User Equipment (UE) 10 

5.3 Application Server (AS) 10 

6 Roles for registration in the IM CN subsystem 10 

6.1 Introduction 10 

6.2 SCUE 10 

6.3 sec AS 10 

7 Roles for call origination 10 

7.1 Introduction 10 

7.2 SCUE 1 

7.3 sec AS 1 

7.3.1 Distinction of requests sent to the SCC AS 1 

7.3.2 Call origination procedures at the SCC AS 1 

8 Roles for call termination 1 

8.1 Introduction 1 

8.2 SCUE 1 

8.3 SCC AS 12 

8.3.1 Distinction of requests sent to the SCC AS 12 

8.3.2 Call termination procedures in the SCC AS 12 

9 Roles for PS-CS session continuity 12 

9.1 Introduction 12 

9.2 SCUE 12 

9.2.1 SC UE procedures for PS to CS session continuity 12 

9.2.2 SC UE procedures for CS to PS session continuity 13 

9.3 SCC AS 13 

9.3.1 Distinction of requests sent to the SCC AS 13 

9.3.2 SCC AS procedures for PS to CS session continuity 13 

9.3.3 SCC AS procedures for CS to PS session continuity 14 

10 Roles for PS-PS session continuity 15 

10.1 Introduction 15 

10.2 SCUE 15 

10.2.1 Full session transfer 16 

10.2.2 Partial session transfer 17 

10.3 SCC AS 17 

10.3.1 Distinction of requests sent to the SCC AS 17 

10.3.2 PS to PS Session Continuity Procedures at the SCC AS 18 



£75/ 



3GPP TS 24.237 version 8.1 .0 Release 8 4 ETSI TS 1 24 237 V8.1 .0 (2009-03) 

11 Roles for PS-PS session continuity in conjunction with PS-CS session continuity 19 

11.1 Introduction 19 

11.2 SCUE 19 

11.2.1 SC UE procedures for PS to PS+CS session continuity 19 

11.2.1.1 General 19 

11.2.1.2 SC UE procedures for PS to PS+CS session continuity using ICS 19 

11.2.1.3 SC UE procedures for PS to PS+CS session continuity not using ICS 19 

11.2.2 SC UE procedures for PS+CS to PS session continuity 20 

11.2.2.1 General 20 

11.2.2.2 SC UE procedures for PS+CS to PS session continuity using ICS 20 

11.2.2.3 SC UE procedures for PS+CS to PS session continuity not using ICS 20 

11.3 sec AS 21 

11.3.1 Distinction of requests sent to the SCC AS 21 

11.3.2 SCC AS procedures for PS to PS+CS session continuity 21 

11.3.3 SCC AS procedures for PS+CS to PS session continuity 21 

12 Roles for PS-CS session continuity, Single Radio 22 

12.1 Introduction 22 

12.2 SC UE procedures for PS to CS session continuity, SR-VCC 22 

12.2.1 General 22 

12.2.2 ICS-based 22 

12.2.3 Not based on ICS 23 

12.3 SCC AS 23 

12.3.1 SCC AS procedures for PS to CS session continuity, SR-VCC 23 

13 Roles for media adding/deleting 24 

13.1 Introduction 24 

13.2 SCUE 24 

13.2.1 Adding or removing media through Gm 24 

13.2.2 Adding Gm control to existing CS session 24 

13.3 SCC AS 25 

13.3.1 Adding or removing media through Gm 25 

13.3.2 Adding Gm control to existing CS session 25 

Annex A (informative): Example signalling flows 26 

A.l Scope of signalling flows 26 

A.2 Introduction 26 

A.2.1 General 26 

A. 2. 2 Key required to interpret signalling flows 26 

A.3 Signalling flows for registration 27 

A. 3.1 Introduction 27 

A. 3. 2 Signalling flows for multiple registration 27 

A.4 Signalling flows for call origination 31 

A.4.1 Session origination for CS calls 31 

A.5 Signalling flows for call termination 31 

A.5.1 Session termination using CS media 31 

A. 6 Signalling flows for PS-CS session continuity 31 

A.6.1 PS-CS access transfer: CS-PS 31 

A.6.2 PS-CS access transfer: PS-CS 35 

A.7 Signalling flows for PS-PS session continuity 38 

A.7.1 Introduction 38 

A. 7. 2 PS-PS access transfer with full media transfer 38 

A.7. 3 PS-PS access transfer with partial media transfer 45 

A. 8 Signalling flows for PS-PS session continuity in conjunction with PS-CS session continuity 53 

A.8.1 Introduction 53 

A.8.2 PS - PS in conjunction with PS - CS Access Transfer: PS to CS 54 

A.8.3 PS - PS in conjunction with PS - CS Access Transfer: CS to PS 61 



£75/ 



3GPP TS 24.237 version 8.1 .0 Release 8 5 ETSI TS 1 24 237 V8.1 .0 (2009-03) 

A.9 Signalling flows for media adding/deleting 65 

Annex B (informative): Change history 69 

History 71 



£75/ 



3GPP TS 24.237 version 8.1 .0 Release 8 6 ETSI TS 1 24 237 V8.1 .0 (2009-03) 



Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



IP Multimedia (IM) Core Network (CN) subsystem Service Continuity (SC) provides the capability of continuing 
ongoing communication sessions with multiple media across different access networks or across different user 
equipments (UEs) under the control of the same subscriber. 

NOTE: Multiple media across different UEs under the control of the same subscriber is not specified in this 
version of the document. 

The present document provides the protocol details for enabling IMS SC based on the Session Initiation protocol (SIP) 
and the Session Description Protocol (SDP) and the protocols of the 3GPP Circuit-Switched (CS) domain (e.g. CAP, 
MAP, ISUP, BICC and the NAS call control protocol for the CS access). 

The present document is applicable to User Equipment (UEs) and Application Servers (AS) providing IMS Service 
Continuity capabilities. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] 3GPP TS 24.229: "IP multimedia call control protocol based on Session Initiation Protocol (SIP) 

and Session Description Protocol (SDP); Stage 3". 

[3] 3GPP TS 24.228 Release 5: "Signalling flows for the IP multimedia call control based on Session 

Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3". 

[4] 3GPP TS 24.292: "IP Multimedia (IM) Core Network (CN) subsystem CentraUzed Services (ICS); 

Stage 3". 

[5] 3GPP TS 24.216: "Communication continuity managed object". 

[6] 3GPP TS 29.328: "IP Multimedia Subsystem (IMS) Sh interface; Signalling flows and message 

contents". 

[7] 3GPP TS 29.329: "Sh interface based on the Diameter protocol; Protocol details". 

[8] 3GPP TS 24.008: "Mobile radio interface layer 3 specification; Core Network protocols; Stage 3". 

[9] 3GPP TS 23.237: "IP Multimedia subsystem (IMS) Service Continuity; Stage 2". 

[10] IETF RFC 3891: "The Session Initiation Protocol (SIP) "Replaces" Header". 

[II] IETF RFC 4538: "Request Authorization through Dialog Identification in the Session Initiation 
Protocol (SIP)". 

[ 1 2] 3GPP TS 23 .003 : "Numbering, addressing and identification" . 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following 
apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 3GPP 
3GPP TR 21.905 [1]. 

Dynamic STI: An STI dynamically assigned by the SCC AS, representing the SIP dialog identifier (Call-ID header 
field and the values of tags in To and From header fields) and used for session transfer request when Gm service control 
is available. 

Static STI: An STI configured in the SC UE either as a SIP URI or as an E.164 number in tel URI or SIP URI 
representation of tel URL The static STI is used for CS-PS transfer when dynamic STI is unavailable. 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.292 [4] apply: 

Correlation MSISDN 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.237 [9] apply: 

Access Leg 

Remote Leg 

Target Access Leg 

Source Access Leg 

Session Transfer Identifier (STI) 

Session Transfer Number (STN) 

Session Transfer Number for SR-VCC (STN-SR) 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 24.292 [4] apply: 

CS call 
CS media 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.003 [12] apply: 
IP Multimedia Routing Number (IMRN) 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
3GPPTR 21.905 [1]. 

IMRN IP Multimedia Routing Number 

SC Service Continuity 

SCC Service Centralization and Continuity 

SR-VCC Single Radio VCC 

STI Session Transfer Identifier 

STN Session Transfer Number 

STN-SR Session Transfer Number - Single Radio 
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4 Overview of IP Multimedia (IIVI) Core Network (CN) 

subsystem Service Continuity 

4.1 General 

In general, IMS Service Continuity provides the capability of continuing ongoing communication sessions with multiple 
media across different access networks. The main need for such continuity arises because user equipments (UEs) with 
multimedia capabilities can move across a multiplicity of different access networks. 

The following procedures are provided within this document: 

procedures for registration in IM CN subsystem are specified in clause 6; 

procedures for call origination are specified in clause 7; 

procedures for call termination are specified in clause 8; 

procedures for PS-CS session continuity are specified in clause 9; 

procedures for PS-PS session continuity are specified in clause 10; 

procedures for PS-PS session continuity in conjunction with PS-CS session continuity are specified in clause 11; 

procedures for PS-CS session continuity for Single Radio are specified in clause 12; and 

procedures for media adding/deleting in clause 13. 

For a UE or an AS not supporting ICS procedures, PS-CS service continuity is only possible when the UE is active in a 
single full-duplex speech or speech/video session i.e. support of session transfer with more than one sessions or with 
non voice media is not provided. 

4.2 Underlying network capabilities 

SC assumes the use of a number of underlying network capabilities: 

1) provision by the home network operator of SCC AS on the IM CN subsystem, as specified in 

3GPPTS 24.229 [2]; 

2) if ICS is used, the network capabilities as specified in 3GPP TS 24.292 [4]; 

4.3 URI and address assignments 

In order to support SC to a subscriber, the following URI and address assignments are assumed: 

a) in this version of the document, the SC UE will be configured with both a static STI and a static STN. The static 
STI is used by the SC UE to perform CS to PS session transfer when no dynamically assigned STI is provided to 
the UE over the CS domain (e.g. when the SC UE does not support ICS capabilities). The static STN is used by 
the SC UE to perform PS to CS session transfer when no service control signalling path as specified in 

3GPP TS 24.292 [4] is available. 

b) the SC UE will be configured to be reachable in both the IM CN subsystem and the CS domain by one or more 
public telecommunication numbers which should be correlated between the CS domain and IM CN subsystem. 
Either: 

this public telecommunication number can be the DN (e.g. MSISDN) used in the CS domain and (in 
international form) comprise part of the implicit registration set associated with that SC UE in the IM CN 

subsystem; or 

the SCC AS can be configured to provide a functional relationship between separate numbers providing each 
of these identities in the CS domain and the IM CN subsystem, respectively. 
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5 Functional entities 

5.1 Introduction 

This clause associates the functional entities with the SC roles described in the stage 2 architecture document (see 
3GPP TS 23.237 [9]). 



5.2 User Equipment (UE) 



To be compliant with this document, a UE shall implement the role of a SC UE (see subclause 6.2, subclause 7.2, 
subclause 8.2, subclause 9.2, subclause 10.2, subclause 11.2 and subclause 12.2). 

5.3 Application Server (AS) 

To be compliant with this document, a AS shall implement the role of a SCC AS (see subclause 6.3, subclause 7.3, 
subclause 8.3, subclause 9.3, subclause 10.3, subclause 11.3 and subclause 12.3). 

6 Roles for registration in the IM CN subsystem 

6.1 Introduction 

A 3rd-party registration shall be performed via the ISC interface for the SCC AS. 

6.2 SC UE 

The SC UE shall follow the procedures specified in 3GPP TS 24.229 [2] for registration of the UE in the IM CN 

subsystem. 

Prior to making use of IMS ICS procedures, the UE shall follow the procedures specified in 3GPP TS 24.292 [4] for 
registration of the ICS UE in the IM CN subsystem. 

6.3 SCC AS 

The SCC AS can obtain registration state information that it needs to implement SCC specific requirements from: 

a) any received third-party REGISTER request (e.g. including information contained in the body of the third-party 
REGISTER request) as specified in 3GPP TS 24.229 [2]; 

b) any received reg event package as specified in 3GPP TS 24.229 [2]; or 

c) the Sh interface as specified in 3GPP TS 29.328 [6] and 3GPP TS 29.329 [7]. 



Roles for call origination 



7.1 Introduction 

This clause specifies the procedures for call origination, both where the SC UE is generating calls in the CS domain and 
where the SC UE is generating calls using the IM CN subsystem. Procedures are specified for the SC UE and the SCC 
AS. 
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7.2 SC UE 

The SC UE shall support origination of multimedia sessions in the IM CN subsystem as specified in 

3GPPTS 24.229 [2]. 

The sec UE shall support origination of calls in the CS domain as specified in 3GPP TS 24.008 [8]. 

The procedures for call origination where the SC UE is initiating calls using CS media are identical to that for ICS UE 
specified in 3GPP TS 24.292 [4]. 

7.3 sec AS 

7.3.1 Distinction of requests sent to tine SCC AS 

The SCC AS needs to distinguish between the following initial SIP INVITE requests to provide specific functionality 
relating to call origination: 

SIP INVITE requests routed to the SCC AS over the ISC interface as a result of processing filter criteria at the S- 
CSCF according to the origination procedures as specified in 3GPP TS 24.229 [2], and therefore distinguished 
by the URI relating to this particular filter criteria appearing in the topmost entry in the Route header. In the 
procedures below, such requests are known as "SIP INVITE requests due to originating filter criteria". It is 
assumed that the SCC AS is the first AS that the S-CSCF forwards the request to after receiving the request from 
the UE. 

Other SIP initial requests for a dialog, and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [8]. 

7.3.2 Call origination procedures at the SCC AS 

When the SCC AS receives a SIP INVITE request due to originating filter criteria, the SCC AS shall follow the SCC 
AS roles for call origination procedures specified in 3GPP TS 24.292 [4]. 



8 Roles for call termination 

8.1 Introduction 

This clause specifies the procedures for call termination, both where the SC UE is receiving calls in the CS domain and 
where the SC UE is receiving calls using the IM CN subsystem. Procedures are specified for the SC UE and the SCC 
AS. 

8.2 SC UE 

The SC UE shall support termination of multimedia sessions in the IM CN subsystem as specified in 
3GPPTS 24.229 [2]. 

The SC UE shall support termination of calls in the CS domain as specified in 3GPP TS 24.008 [8]. 

The procedures for call termination where the SC UE is receiving calls using CS media are identical to that for ICS UE 
roles for call termination procedures which are specified in 3GPP TS 24.292 [4]. 
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8.3 sec AS 

8.3.1 Distinction of requests sent to tine SCC AS 

The SCC AS needs to distinguish between the following initial SIP INVITE requests to provide specific functionality 
relating to call termination: 

SIP INVITE requests routed to the SCC AS over the ISC interface as a result of processing filter criteria at the S- 
CSCF according to the termination procedures as specified in 3GPP TS 24.229 [2], and therefore distinguished 
by the URI relating to this particular filter criteria appearing in the topmost entry in the Route header. In the 
procedures below, such requests are known as "SIP INVITE requests due to terminating filter criteria". It is 
assumed that the SCC AS is the last AS that the S-CSCF forwards the request to. 

Other SIP initial requests for a dialog, and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [2]. 

8.3.2 Call termination procedures in the SCC AS 

When the SCC AS receives a SIP INVITE request due to terminating filter criteria, the SCC AS shall follow the SCC 
AS roles for call termination procedures specified in 3GPP TS 24.292 [4]. 



Roles for PS-CS session continuity 



9.1 Introduction 

For a UE or an AS not supporting ICS procedures, PS-CS service continuity is only possible when the UE is active in a 
single full-duplex speech or speech/video session i.e. support of session transfer with more than one sessions or with 
non voice media is not provided. 

9.2 SO UE 

9.2.1 SC UE procedures for PS to CS session continuity 

The SC UE may be engaged in one or more ongoing IMS sessions at the time of initiating session continuity. By an 
ongoing IMS session, it is meant a session for which the 2xx response for the initial SIP INVITE request to establish 
this session has been sent or received. 

If the SC UE is using Gm, then for each session to be transferred and starting with the active session, the SC UE shall 
send a SIP INVITE request to the SCC AS according to the ICS UE using Gm procedures for call origination as 
specified in 3GPP TS 24.292 [4]. The SC UE shall populate the SIP INVITE request as specified for PS-PS session 
continuity with full media transfer in subclause 10.2.1. 

If the SC UE is not using ICS capabilities, then session continuity is only possible when the UE is active in a single full- 
duplex speech session. If multiple full-duplex speech sessions exist, the SC UE shall first initiate the release of all the 
ongoing full-duplex speech sessions that are currently not active. When transferring the active session, the SC UE shall 
send, to the SCC AS, a message (e.g. CC_SETUP as specified in 3GPP TS 24.008 [8]) to set up a call over the CS 
domain. When sending CC_SETUP, the SC UE shall populate the CC_SETUP as follows: 

1) the called party BCD number information element set to the static STN. 

If the SC UE receives a release message to the CC SETUP message sent, then PS-CS session continuity has not 
completed successfully and the call will continue in the Source Access Leg. 



£75/ 



3GPP TS 24.237 version 8.1 .0 Release 8 1 3 ETSI TS 1 24 237 V8.1 .0 (2009-03) 

9.2.2 SC UE procedures for CS to PS session continuity 

The SC UE may be engaged in one or more ongoing sessions before performing session continuity. By an ongoing 
session, it is meant a CS call for which the CS call setup procedure is complete, e.g. CC CONNECT message has been 
sent or received as described in 3GPP TS 24.008 [8] or a call for which the 2xx response for the initial SIP INVITE 
request to establish this session has been sent or received. 

If not already IMS registered, the SC UE shall follow the procedures specified in subclause 6.2 to perform IMS 
registration over the Target Access Leg before performing CS to PS session continuity. 

If the original sessions are established using ICS capabilities, then for each session to be transferred and starting with 
the active session, the SC UE shall send a SIP INVITE request to the SCC AS in accordance with the UE procedures 
specified in 3GPP TS 24.229 [2] . The SC UE shall populate the SIP INVITE request as specified for PS-PS session 
continuity with full media transfer in subclause 10.2.1. 

If the original sessions are not established using ICS capabilities, then session continuity is only possible when the SC 
UE is active in a single full-duplex speech session. If multiple full-duplex speech sessions exist, the SC UE shall first 
initiate the release of all the ongoing sessions that are currently not active. When transferring the active session, the SC 
UE shall send a SIP INVITE request to the SCC AS in accordance with the UE procedures specified in 
3GPP TS 24.229 [2] . The SC UE shall populate the SIP INVITE request as specified for PS-PS session continuity with 
full media transfer in subclause 10.2.1 with the following differences: 

1) the Request-URI set to the tel URI of the static STL 

If the SC UE receives any SIP 4xx - 6xx response to the SIP INVITE request, then session transfer has not occurred 
and the call will continue in the CS domain. 

When the SC UE receives a CS call release message, e.g. CC DISCONNECT message as specified in 
3GPP TS 24.008 [8], from the network, the SC UE shall comply with network initiated call release procedures to 
release the CS bearer. When CC_DISCONNECT message is received, the SC UE shall comply with the network 
initiated call release procedures as specified in 3GPP TS 24.008 [8]. 

9.3 SCC AS 

9.3.1 Distinction of requests sent to tine SCC AS 

The SCC AS needs to distinguish between the following initial SIP INVITE requests to provide specific functionality 
relating to access transfer: 

SIP INVITE requests routed to the SCC AS containing a STI belonging to the subscribed user in the Replaces 
header field or Target-Dialog header field. In the procedures below, such requests are known as "SIP INVITE 
requests due to STI ". 

SIP INVITE requests routed to the SCC AS containing a static STI in the Request-URI. In the procedures 
below, such requests are known as "SIP INVITE requests due to static STI". 

- SIP INVITE requests routed to the SCC AS containing either a static STN, a STN-SR or an IMRN (as 

described in 3GPP TS 24.292 [4]) in the Request-URI. In the procedures below, such requests are known as 
"SIP INVITE requests due to static STN ". 

NOTE: The media streams that need to be transferred are identified using information described in the subsequent 
sections. 

Other SIP initial requests for a dialog and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [2]. 

9.3.2 SCC AS procedures for PS to CS session continuity 

When the SCC AS receives a SIP INVITE request due to STI on the Target Access Leg, the SCC AS shall follow the 
procedures specified in subclause 10.3.2. 
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When the SCC AS receives SIP INVITE request due to static STN, the SCC AS shall associate the SIP INVITE request 
with an ongoing SIP dialog based on information associated with the received IMRN (as described in 
3GPP TS 24.292 [4]) or based on information from the SIP History-Info header field and P- Asserted header field and 
send a SIP re-INVITE request towards the remote UE using the existing established dialog. By an ongoing SIP dialog, it 
is meant a dialog for which a SIP 2xx response to the initial SIP INVITE request has been sent or received. Multiple 
dialogs associated with the same SCC UE may have been anchored when the SCC AS receives a SIP INVITE request 
due to static STN. This can occur in the event that the UE does not succeed in releasing all inactive dialogs. The 
identification of the associated dialog is subject to the following conditions: 

if only one SIP dialog exists for the user identified in the P-Asserted-Identity header field and a SIP 2xx response 
has been sent and there is active audio media, then continue the session transfer; 

if no SIP dialogs exist for the user identified in the P-Asserted-Identity header field where there is active audio 
media and a SIP 2xx response has been sent, then send a SIP 480 (Temporarily Unavailable) response to reject 
the SIP INVITE request relating to the session transfer; 

if more than one SIP dialog exists for the user identified in the P-Asserted-Identity header field for which SIP 
2xx responses have been sent and there is active audio media on each of them, then the SCC AS shall perform 
session transfer procedures for the dialog that originates from the same device that initiated the received INVITE 
request d u e to static STN. If more than one such dialogs exists from the same device, the SCC AS shall proceed 
with the next step in this list; and 

NOTE 1 : Whether the dialog originates from the same UE as the received SIP INVITE request is determined based 
on local information and information related to the c orrelation MSISDN of the originating user as 
determined via registration procedures as defined in subclause 6.3. 

if more than one SIP dialog exists for the user identified in the P-Asserted-Identity header field and exactly one 
dialog exists where there is active audio media and a SIP 2xx response has been sent for that dialog, then: 

if the remaining dialogs have inactive audio media, then the SCC AS may release the inactive dialogs and 
continue the session transfer procedures; or 

if the SCC AS is not able to identify one dialog for session transfer, then the SCC AS shall send a SIP 480 
(Temporarily Unavailable) response to reject the SIP INVITE request relating to the session transfer. 

Continuing the session transfer procedures, the SCC AS shall populate the SIP re-INVITE request as follows: 

1) set the Request-URI to the URI contained in the Contact header field returned at the creation of the dialog with 
the remote UE; and 

2) a new SDP offer, including the media characteristics as received in the SIP INVITE request due to static STN, 
by following the rules of the 3GPP TS 24.229 [2]. 

Upon receiving the SIP ACK request from the IM CN subsystem, the SCC AS shall initiate release of the source access 
leg by sending a SIP BYE request toward the S-CSCF for sending to the served SCC UE. 

9.3.3 SCC AS procedures for CS to PS session continuity 

When the SCC AS receives a SIP INVITE request due to STI on the Target Access Leg, the SCC AS shall follow the 
procedures specified in subclause 10.3.2. 

When the SCC AS receives a SIP INVITE request due to static STI, the SCC AS shall associate the SIP INVITE 
request with an ongoing SIP dialog. By an ongoing SIP dialog, it is meant a dialog for which a SIP 2xx response to the 
initial SIP INVITE request has been sent or received. Multiple dialogs associated with the same SCC UE may have 
been anchored when the SCC AS receives a SIP INVITE request due to static STI. This can occur in the event that the 
UE does not succeed in releasing all inactive dialogs, in which case the identification of the associated dialog is subject 
to the following conditions: 

if only one SIP dialog exists for the user identified in the P-Asserted-Identity header field and a 2xx response has 
been sent and there is active audio media, then continue the session transfer procedures; 

if no SIP dialogs exist for the user identified in the P-Asserted-Identity header field where there is active audio 
media and a SIP 2xx response has been sent, then send a SIP 480 (Temporarily Unavailable) response to reject 
the SIP INVITE request relating to the session transfer; 
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if more than one SIP dialog exists for the user identified in the P-Asserted-Identity header field and exactly one 
dialog exists where there is active audio media and a SIP 2xx response has been sent for that dialog, then: 

if the remaining dialogs have inactive audio media, then the SCC AS may release the inactive dialogs and 
continue the session transfer procedures; or 

if the SCC AS is not able to identify one dialog for session transfer, then the SCC AS shall send a SIP 480 
(Temporarily Unavailable) response to reject the SIP INVITE request relating to the session transfer. 

Continuing the session transfer procedures, the SCC AS sends a SIP re-INVITE request towards the remote UE using 
the existing established dialog. The SCC AS shall populate the SIP re-INVITE request as follows: 

1) set the Request-URI to the URI contained in the Contact header field returned at the creation of the dialog with 
the remote UE; and 

2) a new SDP offer, including the media characteristics as received in the SIP INVITE request due to the static STI, 
by following the rules of the 3GPP TS 24.229 [2]. 

Upon receiving the SIP ACK request originated from the UE, the SCC AS shall initiate release of the source access leg 
by sending a SIP BYE request over the source access leg. 

If, subsequent to initiating the SIP re-INVITE request to the remote UE, and prior to the SIP ACK request originated 
from the UE being received from the IM CN subsystem for the source access leg, the SCC AS decides (for any reason) 
to reject the session transfer request back to the UE (e.g. by sending a 4xx response), the SCC AS shall release the 
target access leg and maintain the source access leg. 



1 Roles for PS-PS session continuity 

10.1 Introduction 

This clause specifies the procedures for PS-PS session continuity for both full media transfer case and partial media 
transfer case. Procedures are specified for the SC UE and the SCC AS. 

10.2 SCUE 

The SC UE may be engaged in one or more ongoing sessions before performing session continuity. By an ongoing 
session, it is meant a session for which the SIP 2xx response for the initial SIP INVITE request to establish this session 
has been sent or received. 

The SC UE may receive the operator policy via OMA Device Management, see 3GPP TS 24.216 [5]. When the SC UE 
receives the operator policy, for each session to be transferred, it shall take the operator policy into account when 
deciding to perform the following: 

- selecting the access for initiating the PS-PS transfer; 

- determining whether to transfer full or partial media during PS-PS transfer; or 

- determining whether to add or remove media during the PS-PS transfer. 

If the SC UE is configured with the operator policy (e.g. via OMA Device Management as described in the 
3GPP TS 24.216 [5]) then, for each media or group of media contained in the MediaorGroup node, the UE shall: 

1) restrict originating sessions and session transfer towards the access networks contained in the 
RestrictedAccessNetworkType node and; 

2) consider the list of access networks contained in the PreferredAccessNetworks node in the order of priority from 
the access networks such that, when available, the highest priority access network can be used for originating 
sessions and session transfer procedures; 
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3) if a new access network gets available- transfer media components to a higher priority target network than the 
current access network based on the value contained in the SC_media_transfer node value. If the 
SC_media_transfer node value is: 

"shall" the UE shall start a session transfer according to the home operator' s list of preferred access networks 
contained in the PreferredAccessNetworks node; 

"should" the UE is recommended to start session transfer according to the home operator' s list of preferred 
access networks contained in the PreferredAccessNetworks node. The UE can evaluate if session transfer is 
possible and desirable after having taken into account the Local Operating Environment Information; 

"may" the UE can decide whether or not to start session transfer in accordance with user preferences if 
configured in the UE. The UE can evaluate if session transfer is possible and desirable after having taken into 
account the Local Operating Environment Information. If user preferences are not configured, the UE can 
evaluate the home operator' s list of preferred access networks contained in the PreferredAccessNetworks 
node. 

4) decide whether to keep or drop non transferable media components in the case of partial session transfer based 
on the SC_non_transferrable_media node value. 

The SC UE shall follow the procedures specified in subclause 6.1 to perform IMS registration over the Target Access 
Leg before performing PS-PS session continuity. 

1 0.2.1 Full session transfer 

To initiate PS-PS session continuity for a session, the SC UE shall send a SIP INVITE request over the Target Access 
Leg in accordance with UE procedures specified in 3GPP TS 24.229 [2]. The SC UE shall populate the SIP INVITE 
request as follows: 

1 . the Request-URI set to the URI contained in the Contact header field returned at the creation of the dialog over 
the Source Access Leg; 

2. include in the Contact header field: 

A a public GRUU or temporary GRUU as specified in 3GPP TS 24.229 [2] if a GRUU was received at 
registration; and 

B the media feature tag g.3gpp.ics set to "principal" as specified in annex B of 3GPP TS 24.292 [4]; 

3. select one of the following options: 

A. if usage of SIP Replaces extension is selected: 

a. the Replaces header field populated as specified in IETF RFC 3891 [10], containing the dialog identifier 
of the session to be transferred; and 

b. the Require header field populated with the option tag value "replaces"; 

B. if usage of SIP Target-Dialog extension is selected: 

a. the Target-Dialog header field populated as specified in IETF RFC 4538 [11], containing the dialog 
identifier of the session to be transferred; and 

b. the Require header field populated with the option tag value "tdialog"; and 

4 . the SDP payload set for the media component(s) to be transferred, in accordance with the UE SDP 

origination procedures specified in 3GPP TS 24.229 [2]. The SDP shall contain the same number of media lines, 
each corresponding to one of the media components in the original session, unless media components need to be 
added. Each media line shall indicate the same media type as its corresponding media component in the original 
session and shall contain at least one codec that was negotiated during the original session. 

A) If the SC UE determines to remove a media component during the transfer, then the media line for this 
media component shall include a port number with value zero; and 
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B) If the SC UE determines to add new media component(s) during the transfer, then one additional media 
Hne with the desired media type and codecs shall be added for each new media component at the end of 
the SDP. 

Upon receiving SIP 2xx response for the SIP INVITE request sent over the Target Access Leg and sending SIP ACK 
request, if the dialog over the Source Access Leg is still active, the SC UE shall send a SIP BYE request to the SCC AS 
over the Source Access Leg to terminate the original session. 

If the SC UE receives any SIP 4xx - 6xx response to the SIP INVITE request sent over the Target Access Leg, then PS- 
PS session continuity has not completed successfully and the call will continue in the Source Access Leg. 

1 0.2.2 Partial session transfer 

To initiate PS-PS session continuity for a session, the SC UE shall send a SIP INVITE request over the Target Access 
Leg in accordance with UE procedures specified in 3GPP TS 24.229 [2]. The SC UE shall populate the SIP INVITE 
request as follows: 

the Request-URI set to the URI contained in the Contact header field returned at the creation of the dialog over 
the Source Access Leg; 

include in the Contact header field: 

A a public GRUU or temporary GRUU as specified in 3GPP TS 24.229 [2] if a GRUU was received at 
registration; and 

B the media feature tag g.3gpp.ics set to "principal" as specified in annex B of 3GPP TS 24.292 [4] ; 

the Require header with the option tag 'tdialog' included; 

the Target-Dialog header populated as specified in IETF RFC 4538 [11], containing the dialog identifier of the 
session to be transferred; and 

the SDP payload set for the media component(s) to be transferred, in accordance with the UE SDP origination 
procedures specified in 3GPP TS 24.229 [2]. The SDP shall contain the same number of media lines in the same 
order, each corresponding to one of the media components in the original session, unless media components 
need to be added during the session transfer. Each media line shall indicate the same media type as its 
corresponding media component in the original session and shall contain at least one codec that was negotiated 
during the original session. 

1) If the SC UE determines to keep the media component on the Source Access Leg, then the media line for 

this media component shall include a port number with value zero; and 

2) If the SC UE determines to add new media component(s) during the transfer, then one additional media 

line with the desired media type and codecs shall be added for each new media component at the end of 
the SDP. 

Upon receiving SIP 2xx response for the SIP INVITE request sent over the Target Access Leg and sending SIP ACK 
request, the SC UE shall send a SIP re-INVITE request to the SCC AS over the Source Access Leg to update the 
original session. The SC UE shall populate the SIP re-INVITE request as follows: 

the SDP payload set for all the media component(s) within the original session, in accordance with the UE SDP 
origination procedures specified in 3GPP TS 24.229 [2]. The port number for a media component shall be set to 
zero if that media component has been transferred to the Target Access Leg or has to be removed. 

If the SC UE receives any SIP 4xx - 6xx response to the SIP INVITE request sent over the Target Access Leg, then PS- 
PS session continuity has not completed successfully and the call will continue in the Source Access Leg. 

10.3 SCC AS 

1 0.3.1 Distinction of requests sent to tine SCC AS 

The SCC AS needs to distinguish between the following initial SIP INVITE requests to provide specific functionality 
relating to access transfer: 
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SIP INVITE requests routed to the SCC AS containing a STI belonging to the subscribed user in the Replaces 
header or Target-Dialog header. In the procedures below such requests are known as "SIP INVITE requests due 
to STI ". 

NOTE: The media streams that need to be transferred are identified using information described in the subsequent 
sections. 

Other SIP initial requests for a dialog and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [2]. 

1 0.3.2 PS to PS Session Continuity Procedures at tine SCC AS 

When the SCC AS receives a SIP INVITE request on the Target Access Leg due to STI, the SCC AS shall: 

associate the SIP INVITE received on the Target Access Leg with an ongoing SIP dialog i.e. identify the 
Source Access Leg. The Source Access Leg is identified by matching the dialog ID present in the Replaces (see 
IETF RFC 3891 [10]) or Target Dialog header (see IETF RFC 4538 [1 1]) of the SIP INVITE with an ongoing 
dialog. By an ongoing SIP dialog, it is meant a dialog for which a SIP 2xx response to the initial SIP INVITE 
request has been sent or received; 

if the SCC AS is unable to associate the SIP INVITE with a unique ongoing dialog, send a SIP 480 
(Temporarily Unavailable) response to reject the SIP INVITE request relating to the access transfer and not 
processes the remaining steps; 

if the SIP INVITE request contains a Replaces header: 

a) follow the procedures defined in IETF RFC 3891 [10] for replacing the Source Access Leg with the SIP 
request received on the Target Access Leg, including terminating the Source Access Leg by sending a SIP 
BYE towards the SC UE in accordance with 3GPP TS 24.229 [8]; and 

b) send a SIP re-INVITE request towards the remote UE using the existing established dialog. The SCC AS 
shall populate the SIP re-INVITE request as follows: 

1) set the Request-URI to the URI contained in the Contact header field returned at the creation of the dialog 
with the remote UE; and 

2) a new SDP offer, including the media characteristics as received in the SIP INVITE request due to STI 
received on the Target Access Leg, by following the rules of the 3GPP TS 24.229 [2]. 

otherwise, if the SIP INVITE request contains a Target Dialog header: 

a) if the number of media lines in the Target Access Leg is less than the number of media lines in the Source 
Access Leg or the media type for the corresponding media lines is not the same as in the original session, 
send a SIP 4xx response to reject the SIP INVITE request relating to the access transfer and not process the 
remaining steps; 

b) otherwise, send a SIP re-INVITE request towards the remote UE using the existing established dialog. The 
SCC AS shall populate the SIP re-INVITE request as follows: 

1) set the Request-URI to the URI contained in the Contact header field returned at the creation of the dialog 
with the remote UE; and 

2) include a new SDP offer, following the rules specified in 3GPP TS 24.229 [2], containing the following 
media information: 

the media characteristics as received in the SIP INVITE request due to STI received on the Target 
Access Leg for media streams whose port is not set to zero; and 

for the media streams in the SIP INVITE request due to STI whose port is set to zero, include the 
corresponding media characteristics of those streams from the Source Access Leg, 

c) after receiving the SIP ACK request from the SC UE on the Target Access Leg, upon receiving an update 
(e.g. SIP re-INVITE) from the SC UE on the Source Access Leg, process the update request in accordance 
with 3GPPTS 24.229 [2]. 
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If, subsequent to initiating the SIP re-INVITE request to the remote UE, and prior to the SIP ACK request being 
received on the Target Access Leg, the SCC AS decides (for any reason) to reject the access transfer request (e.g. by 
sending a 4xx response), the SCC AS shall release the Target Access Leg, retain the Source Access Leg, and update the 
remote leg to match the Source Access Leg. 



1 1 Roles for PS-PS session continuity in conjunction 
with PS-CS session continuity 

11.1 Introduction 

This clause specifies the procedures for PS-PS session continuity in conjunction with PS-CS session continuity. 
Procedures are specified for the SC UE and the SCC AS. For SC UE or SCC AS not supporting ICS procedures, PS-PS 
session continuity with a remote end in conjunction with PS-CS session continuity with the same remote end is only 
possible when the UE is active in a single CS session with full-duplex speech with the remote end i.e. support of session 
transfer with more than one session containing full-duplex speech component is not provided. 

11.2 SCUE 

11 .2.1 SC UE procedures for PS to PS+CS session continuity 

11.2.1.1 General 

The SC UE may be engaged in one or more ongoing IMS sessions before performing session continuity. By an ongoing 
session, it is meant a session for which the SIP 2xx response for the initial SIP INVITE request to establish this session 
has been sent or received. 

1 1 .2.1 .2 SC UE procedures for PS to PS-i-CS session continuity using ICS 

If the SC UE is using Gm, then for each session to be transferred and starting with the session with active full-duplex 
speech component, the SC UE shall send a SIP INVITE request to the SCC AS as specified for call origination for ICS 
UE using Gm in 3GPP TS 24.292 [4]. The SC UE shall populate the SIP INVITE request as specified for PS-PS session 
continuity with full media transfer in subclause 10.2.1. The SC UE shall indicate in the SIP INVITE request that the 
speech media is using CS bearer. When sending the SIP INVITE request for the sessions with inactive full-duplex 
speech component and if precondition is used, the SC UE shall indicate that the related local preconditions for the 
speech component are met. 

For the session with active full-duplex speech component, upon receiving the PSI DN from the SCC AS, the SC UE 
shall follow the procedures for call origination for ICS UE using Gm in 3GPP TS 24.292 [4] to set up the CS bearer. 

1 1 .2.1 .3 SC UE procedures for PS to PS-i-CS session continuity not using ICS 

If the SC UE is not using ICS capabilities, then session continuity is only possible when the UE is active in a single 
session with full-duplex speech media component. For the non-speech components to be transferred to the PS Target 
Access Leg, the SC UE shall send a SIP INVITE request to the SCC AS as specified for PS-PS session continuity with 
partial media transfer in subclause 10.2.1. For the speech component to be transferred to the CS Target Access leg, the 
SC UE shall send to the SCC AS a CS call setup message, e.g., CC_SETUP as specified in 3GPP TS 24.008 [8]. When 
sending the CC_SETUP, the SC UE shall populate the CC_SETUP as follows: 

1) the called party BCD number information element set to the STN. 

Upon receiving the SIP 2xx response from the SCC AS for the PS Target Access Leg and sending SIP ACK request and 
upon receiving CS call setup confirmation message, e.g. CC_CONNECT message, for the CS Target Access Leg, the 
SC UE shall send a SIP BYE request to terminate the Source Access Leg, following the procedures specified in 

3GPPTS 24.229 [2]. 
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If the SC UE receives any SIP 4xx - 6xx response to the SIP INVITE request for the PS Target Access leg and receives 
CS call setup failure message for the CS Target Access Leg, then session transfer has not occurred and the call will 
continue in the original domains. 

If the SC UE receives any SIP 4xx - 6xx response to the SIP INVITE request for the PS Target Access Leg and 
receives CS call setup confirmation message for the CS Target Access Leg, then the session transfer is only successful 
for part of the media components. The SC UE shall update the Source Access leg by following the procedures specified 
for PS-PS session continuity with partial media transfer in subclause 10.2.2 to indicate that all media components other 
than the speech component are still maintained on the Source Access Leg. 

If the SC UE receives CS call setup failure message for the CS Target Access Leg but receives a SIP 2xx response for 
the PS Target Access Leg, then the session transfer is only successful for part of the media components. Upon sending 
SIP ACK request, the SC UE shall update the Source Access leg by following the procedures specified for PS-PS 
session continuity with partial media transfer in subclause 10.2.2 to indicate that the speech component is still 
maintained on the Source Access Leg. 

1 1 .2.2 SC UE procedures for PS+CS to PS session continuity 

11.2.2.1 General 

The SC UE may be engaged in one or more ongoing sessions before performing session continuity. By an ongoing 
session, it is meant a CS call for which the CC CONNECT message has been sent or received or a call for which the 
SIP 2xx response for the initial SIP INVITE request to establish this session has been sent or received. 

If not already registered over the PS Target Access Leg, the SC UE shall follow the procedures specified in 
subclause 6.2 to perform IM CN subsystem registration over the Target Access Leg before performing PS/CS to PS 
session continuity. 

1 1 .2.2.2 SC UE procedures for PS+CS to PS session continuity using ICS 

If the original sessions are established using ICS capabilities, then for each session to be transferred and starting with 
the session with active full-duplex speech media component, the SC UE shall send a SIP INVITE request to the SCC 
AS in accordance with the UE procedures specified in 3GPP TS 24.229 [2]. The SC UE shall populate the SIP INVITE 
request as specified for PS-PS session continuity with full media transfer in subclause 10.2.1. The SC UE shall indicate 
in the SIP INVITE request that the speech media component is using PS media. 

Upon receiving SIP BYE request for the Source Access Leg, the SC UE shall follow the ICS using Gm procedures 
specified in 3GPP TS 24.292 [4] to release the session. The SC UE also releases the associated CS bearer if no other 
sessions depend on the CS bearer. 

1 1 .2.2.3 SC UE procedures for PS-i-CS to PS session continuity not using ICS 

If the original sessions are not established using ICS capabilities, then session continuity is only possible when the SC 
UE has a single session with active full-duplex speech media component. The SC UE shall send a SIP INVITE request 
to the SCC AS in accordance with the UE procedures specified in 3GPP TS 24.229 [2] . 

The SC UE shall populate the SIP INVITE request as follows: 

- the Request-URI set to static STI; 

the Require header field including "replaces" option tag; 

the Replaces header field populated as specified in IETF RFC 3891 [10], containing the dialog identifier of the 
session to be transferred on the PS Source Access Leg; and 

the SDP payload set for the media component(s) to be transferred, in accordance the UE SDP origination 
procedures specified in 3GPP TS 24.229 [2]. The SDP shall contain media components in the following order: 

1) The same number of media lines, each corresponding to one of the media components in the session on the 
PS Source Access Leg; Each media line shall indicate the same media type as its corresponding media 
component in the original session and shall contain at least one codec that was negotiated during the original 
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session. If the SC UE determines to remove a media component during the transfer, then the media line for 
this media component shall include a port number with value zero; 

2) One speech media component to be transferred, corresponding to the speech media component in the session 
on the CS Source Access Leg; and 

3) If the SC UE determines to add new media component(s) during the transfer, then one additional media line 
with the desired media type and codecs shall be added for each new media component. 

If the SC UE receives any SIP 4xx - 6xx response to the SIP INVITE request, then session transfer has not occurred 
and the call will continue in the original domains. 

1 1 .3 sec AS 

11 .3.1 Distinction of requests sent to tine SCC AS 

The SCC AS needs to distinguish between the following initial SIP INVITE requests to provide specific functionality 
relating to access transfer: 

SIP INVITE requests routed to the SCC AS containing a STI belonging to the subscribed user in the Replaces 
header field or Target-Dialog header field. In the procedures below, such requests are known as "SIP INVITE 
requests due to STI". 

SIP INVITE requests routed to the SCC AS containing either a static STN or an IMRN in the Request-URI. In 
the procedures below, such requests are known as "SIP INVITE requests due to static STN". 

SIP INVITE requests routed to the SCC AS containing a static STI in the Request-URI and a STI in the 
Replaces header field. In the procedures below, such requests are known as "SIP INVITE requests due to two 
STIs". 

NOTE: The media streams that need to be transferred are identified using information described in the subsequent 
subclauses 11.3.2 and 11.3.3. 

Other SIP initial requests for a dialog and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [2]. 

1 1 .3.2 SCC AS procedures for PS to PS+CS session continuity 

When the SCC AS receives a SIP INVITE request due to STI on the Target Access Leg, the SCC AS shall follow the 
PS-PS session continuity procedures specified in subclause 10.3.2. If the SIP INVITE request includes an active speech 
media component using CS bearer, then the SCC AS shall follow the procedures for SCC AS for service control over 
Gm in 3GPP TS 24.292 [4] to send the PSI DN to the SC UE and wait for the SC UE to set up CS bearer before 
sending re-INVITE to the remote end. 

When the SCC AS receives a SIP INVITE request due to static STN on the Target Access Leg, the SCC AS shall 
follow the PS-CS session continuity procedures specified in subclause 9.3.2. However, as the Source Access Leg 
contains media components other than speech component, the SCC AS does not initiate release for Source Access Leg. 

1 1 .3.3 SCC AS procedures for PS+CS to PS session continuity 

When the SCC AS receives a SIP INVITE request due to STI on the Target Access Leg, the SCC AS shall follow the 
PS-PS session continuity procedures specified in subclause 10.3.2. 

When the SCC AS receives a SIP INVITE request due to two STIs on the Target Access Leg, the SCC AS shall: 

associate the SIP INVITE request received on the Target Access Leg with two ongoing sessions: 

a) an ongoing SIP dialog on the PS Source Access Leg: This is done by matching the dialog ID present in the 
Replaces header field (see IETF RFC 3891 [10]) of the SIP INVITE request with an ongoing dialog. By an 
ongoing SIP dialog, it is meant a dialog for which a SIP 2xx response to the initial SIP INVITE request has 
been sent or received; 
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b) a different ongoing SIP dialog with active full-duplex speech component: 

if the sec AS is unable to associate the SIP INVITE request with either one of the above two dialogs, send a 
SIP 480 (Temporarily Unavailable) response to reject the SIP INVITE request relating to the access transfer and 
not process the remaining steps; and 

if the session transfer is possible: 

a) follow the procedures defined in IETF RFC 3891 [10] for replacing the two sessions on the Source Access 
Legs with the SIP request received on the Target Access Leg, including terminating the two Source Access 
Legs by sending a SIP BYE request on each session towards the SC UE in accordance with 

3GPPTS 24.229 [2]; and 

b) send a SIP re-INVITE request towards the remote UE using the existing established dialog. The SCC AS 
shall populate the SIP re-INVITE request as follows: 

1) set the Request-URI to the URI contained in the Contact header field returned at the creation of the dialog 
with the remote UE; and 

2) a new SDP offer, including the media characteristics as received in the SIP INVITE request due to two 
STIs received on the Target Access Leg, by following the rules of the 3GPP TS 24.229 [2]. 



12 Roles for PS-CS session continuity, Single Radio 

12.1 Introduction 

This clause specifies the procedures for PS-CS session continuity in Single Radio VCC. Procedures are specified for the 
SC UE and the SCC AS. For SC UE or SCC AS not supporting ICS procedures, PS-CS session continuity in SR-VCC 
is only possible when the UE is active in a single session with full-duplex speech i.e. support of session transfer with 
more than one session containing full-duplex speech component is not provided. 

12.2 SC UE procedures for PS to CS session continuity, SR- 
VCC 

12.2.1 General 

The SC UE may be engaged in one or more ongoing IMS sessions before SR-VCC session continuity is performed. By 
an ongoing session, it is meant a session for which the SIP 2xx response for the initial SIP INVITE request to establish 
this session has been sent or received. 

12.2.2 ICS-based 

If: 

the Gm reference point is retained upon PS handover procedure; 

the SC UE is using ICS capabilities; and 

- SR-VCC procedures (as described in 3GPP TS 24.008 [8]) have been completed; 

the SC UE, in order to add Gm control for the newly established CS session, shall: 

send a SIP re-INVITE request for each speech session to be transferred, starting with the session with active full- 
duplex speech component that was most recently made active; and 

within the SDP offer indicate the media line for all active and held audio streams as an audio stream over circuit 
switched bearer in accordance with 3GPP TS 24.292 [4]. If the precondition mechanism is used, the SC UE shall 
indicate the related local preconditions as met. 
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NOTE: Within SR-VCC the handover is performed on PS level. Due to this, the SIP dialog established over the 
source PS access network stays the same after SR-VCC procedures, e.g. the IP address of the UE, the 
Call-ID, the P-CSCF do not change. Therefore in this case a re-INVITE needs to be sent to add ICS- 
control for the CS bearer. 

12.2.3 Not based on ICS 

After successful SR-VCC procedures (as described in 3GPP TS 24.008 [8]), if the SC UE is not using ICS capabilities, 
the SC UE shall replace the most recent active PS audio session with the newly established CS voice call. 

NOTE: In the case when ICS is not supported or used, only the most recent active audio call is transferred from 
PS to CS audio. 

If: 

the Gm reference point is retained upon PS handover; 
the SC UE is not using ICS capabilities; and 
- SR-VCC procedures (as described in 3GPP TS 24.008 [8]) have been completed; 
the SC UE shall: 

send a SIP re-INVITE request to the SCC AS as specified for media removal in subclause 13.2.1; and 
indicate in the SDP Offer the full-duplex speech media as removed. 

12.3 SCC AS 

1 2.3.1 SCC AS procedures for PS to CS session continuity, SR-VCC 

The SCC AS needs to distinguish between the following SIP INVITE requests to provide specific functionality for SR- 
VCC: 

SIP INVITE request routed to the SCC AS due to a STN-SR belonging to the subscribed user in the Request- 
URL These SIP INVITE requests originate from the MSC server. In the procedures below, such requests are 
known as "SIP INVITE requests due to STN-SR". 

SIP re-INVITE request routed to the SCC AS containing one or more already existing media lines for audio 
indicate a CS bearer. In the procedures below, such requests are known as "SIP re-INVITE requests adding ICS 
control". 

SIP re-INVITE request routed to the SCC AS containing one or more already existing media lines for audio 
indicate the port set to "0". In the procedures below, such requests are known as "SIP re-INVITE requests for 
non-ICS control". 

When the SCC AS receives a SIP INVITE request due to STN-SR on the Target Access Leg, the SCC AS shall follow 
the PS-CS session continuity procedures specified in subclause 9.3.2 for the session with active full-duplex speech 
component that was most recently made active. However, the SCC AS does not initiate release for Source Access Leg. 

If the SCC AS has sent a SIP 480 (Temporarily Unavailable) response to reject a SIP INVITE request due to STN-SR 

on the Target Access Leg: 

1) if the speech media flow to be transferred was the only media flow in the SIP dialog, the SCC AS shall release 
the remote leg as specified in 3GPP TS 24.229 [2]; or 

2) if the SIP dialog contains other media flows than the active speech flow, the SCC AS shall modify the remote leg 
and remove the speech media flow, as specified in 3GPP TS 24.229 [2]. 

When the SCC AS receives a SIP re-INVITE request for adding ICS control, the SCC AS shall follow the procedures as 
described for ICS using Gm in subclause 13.3.2. 
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NOTE: When using the ICS controlled CS bearer, only one audio call can be active at a time. Nevertheless, 

several calls can be held in parallel. If the user decides to switch to another (previously held) call, the ICS 
controlled CS bearer is re-used for this call. Therefore no specific procedures for handling of held calls in 
the case of ICS controlled CS bearer are needed. 

When the SCC AS receives a SIP re-INVITE for non-ICS control, the SCC AS shall follow the media removal 
procedures as specified in subclause 13.3.1. As only the most recent active audio call is transferred from PS to CS 
audio, the SCC AS all drop all other previously existing audio session from this UE and indicate them accordingly in 
the SDP Offer sent within SIP re-INVITE requests towards the remote UE. 



1 3 Roles for media adding/deleting 

13.1 Introduction 

This clause specifies the procedures for adding or deleting media to an existing multimedia session. Procedures are 
specified for the SC UE and the SCC AS. 

13.2 SCUE 

13.2.1 Adding or removing media tinrougin Gm 

If the SC UE wants to add or remove media to a session that was previously established using Gm, the SC UE shall 
follow the procedures defined in the 3GPP TS 24.229 [2] for adding/removing PS media and shall follow the 
procedures defined in the 3GPP TS 24.292 [4] for adding/removing CS media to the session. 

If the SC UE receives a SIP INVITE request from the remote end to add or remove media to a session that was 
previously established using Gm, the SC UE shall follow the procedures defined in the 3GPP TS 24.229 [2] for adding 
or removing PS media and shall follow the procedures defined in the 3GPP TS 24.292 [4] for adding or removing CS 
media to the session. 

13.2.2 Adding Gm control to existing CS session 

The SC UE shall add Gm control to an existing CS session only when there is a single full-duplex speech session over 
CS. If there is more than one full-duplex speech session, the SC UE shall release all the ongoing sessions that are not 
currently active before attempting the procedures described in this section. 

If the SC UE wants to add Gm control to an existing CS session that was established without Gm, after registering with 
the IM CN subsystem, the SC UE shall send an initial SIP INVITE request over the PS access in accordance with 
3GPP TS 24.229 [2]. The SC UE shall populate the SIP INVITE request as follows: 

- set the Request-URI to the tel URI of static STI; and 

set the SDP payload, in accordance with the procedures defined in 3GPP TS 24.292 [4], proposing an audio 
stream over a circuit switched bearer. The SC UE can optionally include additional PS media to the SDP in 
accordance to the procedures defined in 3GPP TS 24.229 [2]. 

Editor" s note: The contents of the SIP REGISTER are FFS. In particular, it is FFS how the UE chooses the correct 
public user identity to register to ensure that the implicit registration set of this public user identity 
contains the tel URI. 

Upon receiving a SIP 200 (OK) response, the SC UE shall treat the ongoing CS call as established using Gm and shall 
follow the "ICS UE using Gm" procedures defined in 3GPP TS 24.292 [4] for controlling the CS call. 

If the SC UE receives a new SIP INVITE request containing an audio stream over a circuit-switched bearer in the SDP 
and the PSI DN matches the B-party number of the ongoing CS call that was established without Gm, the SC UE shall: 

respond to the SIP INVITE request in accordance with the procedures defined in 3GPP TS 24.292 [4]; and 
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treat the ongoing CS call as established using Gm and shall follow the "ICS UE using Gm" procedures defined in 
3GPP TS 24.292 [4] for controlling the CS call. 

13.3 sec AS 

1 3.3.1 Adding or removing media tinrougin Gm 

When the SCC AS receives a SIP re-INVITE request from the SC UE or remote end to add/remove media to an existing 
session established using Gm, the SCC AS shall follow the procedures defined in 3GPP TS 24.229 [2] for adding or 
removing PS media and shall follow the procedures defined in 3GPP TS 24.292 [4] for adding or removing CS media to 
the session. 

1 3.3.2 Adding Gm control to existing CS session 

If the SCC AS receives a SIP INVITE request containing the static STI in the Request-URI and the SC UE has an 
ongoing CS call, the SCC AS shall: 

respond to the SIP INVITE request in accordance with the procedures defined in 3GPP TS 24.292 [4]; 

treat the ongoing CS call as established using Gm and shall follow the "SCC AS for service control over Gm" 
procedures defined in 3GPP TS 24.292 [4] for controlling the CS call; and 

- if the SIP INVITE request contains additional PS media, the SCC AS shall send a SIP re-INVITE request 
towards the remote end, including the newly added PS media, in accordance with the procedures defined in 

3GPPTS 24.229 [2]. 

The SCC AS shall add Gm control to an existing CS session only when there is a single full-duplex speech session over 
CS. If the SCC AS wants to add Gm control to an existing CS session that was established without Gm, the SCC AS 
shall send a new SIP INVITE request over the PS access in accordance with 3GPP TS 24.229 [2]. The SCC AS shall 
populate the SIP INVITE request as follows: 

set the Request-URI to the public user identity of the UE; and 

set the SDP payload, in accordance with the procedures defined in 3GPP TS 24.292 [4], proposing an audio 
stream over a circuit switched bearer. 

Upon receiving a SIP 200 (OK) response, the SCC AS shall treat the ongoing CS call as established using Gm and shall 
follow the "SCC AS for service control over Gm" procedures defined in 3GPP TS 24.292 [4] for controlUng the CS 
call. 
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Annex A (informative): 
Example signalling flows 

A.1 Scope of signalling flows 

This annex gives examples of signalling flows for Service Continuity based on the Session Initiation Protocol (SIP) and 
SIP Events. 

These signalling flows provide detailed signalling flows, which expand on the overview information flows provided in 
3GPPTS 23.237 [9]. 

A.2 Introduction 
A.2.1 General 

The signalling flows provided in this annex follow the methodology developed in 3GPP TS 24.228 [3]. 

A.2. 2 Key required to interpret signalling flows 

The key to interpret signalling flows specified in 3GPP TS 24.228 [3] subclauses 4. 1 and 4.2 applies with the additions 
specified below: 

tel:+l-237-555-ll 1 1 represents the public user indentity of SC UE A. 

tel:+l-237-555-2222 represents the public user indentity of UE B. 

sip:sccasl. homel.net represents the Internet host of SCC AS. 

Each signalling flow table contains descriptions for headers where the content of the header is new to that signalling 
flow, as is already performed in 3GPP TS 24.228 [3]. 

However, 3GPP TS 24.228 [3] includes extensive descriptions for the contents of various headers following each of the 
tables representing the contents of the signalling flows. Where the operation of the header is identical to that shown in 
3GPP TS 24.228 [3], then such text is not reproduced in the present document. 

Additional text may also be found on the contents of headers within 3GPP TS 24.228 [3] in addition to the material 
shown in the present document. 

In order to differentiate between messages for SIP and media, the notation in figure A.2-1 is used. 

INVITE 
► SIP message 



SETUP 
► CS message 



Media over a PS connection 



Media over a CS connection 



Figure A.2-1 : Signalling flow notation 
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A.3 Signalling flows for registration 
A.3.1 Introduction 

When using CS access for media and to make use of the IMS ISC procedures, the SC UE is registered in IM CN 
subsystem and the signalling flows are defined in 3GPP TS 24.292 [4] subclause A.2. 

When initiating a CS call, the SC UE can be registered in the CS domain as defined in 3GPP TS 24.008 [8]. 

Whenever the UE acquires IP connectivity via an IP-CAN, the signalling fiows for registration in the IMS are defined 

in3GPPTS24.228[3]. 

A.3. 2 Signalling flows for multiple registration 

The signalling flows shown in figure A. 3. 2-1 gives an example when a UE connects to different IP-CAN respectively 
and performs multiple registrations. In this example the SCC AS receives the registration state information that it needs 
to implement SCC specific requirements from the third-party REGISTER request. 



UE 



— 1. SIPRegister#l- 



P-CSCF#1 



-6. 200 OK- 



9.UE connects to a 
new IP-CAN 



P-CSCF#2 



I-CSCF 



-2. SIP Register#l- 



0. SIP Register#2- 



-15. 401 Unauthorized- 



I 



-16. SIPRegister#2- 



-21.200OK- 



-5. 200 OK- 



11. SIP 

Register#2 



14.401 

a 

Unauthorized 

_ 17. SIP 
Register#2 



120. 200 OK- 



S-CSCF 



3. SIP 

Register#l 
-4. 200 OK- 



_ 12. SIP 
Register#2 
13.401 
Unauthorized 



18. SIP 

Register#2 

-19.200OK- 



SCCAS 



-7. SIP Registei»> 
•-8. 200 OK— 



-22. SIP Register*- 
"•-23. 200 OK — 



Figure A.3.2-1 Signalling flows for multiple registrations 

1. SIP REGISTER request (UE to P-CSCF#1)-See example in table A.3.2-1 

UE sends the SIP REGISTER request via the IP-CAN#I. 
NOTE 1: For clarity, the unprotected SIP REGISTER request via the IP-CAN#1 is not shown in this example. 
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Table A.3.2-1SIP REGISTER request (UE to P-CSCF#1) 



REGISTER sipiregistrar .homel .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : ddd] : 1357;comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: <sip :userl_publicl@homel .net>; tag=4f a3 

To : <sip :userl_publicl@homel .net> 

Contact: <sip: [5555 :: aaa :bbb : ccc :ddd] : 1357;comp=sigcomp>; reg-id=l; +sip . instance="< 
urn:gsma: imei : 90420156-025763-0 >";+g. 3gpp. icsi-ref ="urn%3Aurn-7%3gpp- 
service . ims . icsi .mmtel" ; +g. 3gpp. ics= "principal" ;expires=600000 

Call -ID: apb03a0s0 9dkjdfglkj4 9111 

Authorization: Digest username="userl_private@homel .net" , realm="registrar .homel .net" , 
nonce=base64 (RAND + AUTN + server specific data), algorithm=AKAvl-MD5, 
uri=" sip: registrar .homel .net" , response="662 9fae4 93 93a053 9 745 097 85 07c4ef 1" 

Security-Client: ipsec-3gpp; alg=hmac-sha-l-96 ; spi-c=23456789; spi-s=12345678 ; port-c=246e 
port-s=1357 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c = 98765432 ; spi -s =8765432 1 ; port- 
c=8642; port-s=7531 

Require: sec -agree 

Proxy-Require: sec-agree 

CSeq: 2 REGISTER 

Supported: path, outbound, gruu 

Content-Length: 



2. SIP REGISTER request (P-CSCF#1 to I-CSCF)-See example in table A.3.2-2 

After performing the DNS query, the P-CSCF#1 forwards the REGISTER request towards I-CSCF. The P-CSCF 
adds a Path header with a flow token and includes the 'ob' parameter 

Table A.3.2-2 SIP REGISTER request (P-CSCF#1 to I-CSCF) 



REGISTER sip:registrar .homel .net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 

[5555 : :aaa:bbb: ccc :ddd] : 13 57 ; comp=sigcomp ; branch=z9hG4bKnashds7 
Max-Forwards: 69 
P-Access-Network-Info : 

Path: <sip: VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib@pcscf 1 .visitedl . net ; Ir ;ob> 
Require: path 

P-Visited-Network-ID : "Visited Network Number 1" 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=02 3 551024" 
From: 
To: 

Contact : 
Call-ID: 
Authorization: Digest username="userl_private®homel .net" , realm="registrar .homel .net" , 

nonce=base64 (RAND + AUTN + server specific data), algorithm=AKAvl-MD5 , 

uri=" sip: registrar .homel .net" , response="662 9f ae4 93 93a053 9745 97 85 07c4ef 1" , integrity- 

protected="yes" 
CSeq: 

Supported: 
Content-Length : 



3. SIP REGISTER request (I-CSCF to S-CSCF) 

The I-CSCF forwards the SIP REGISTER request to the S-CSCF. 

4. SIP 200 (OK) response (S-CSCF to I-CSCF)-See example in table A.3.2-4 

The S-CSCF sends a SIP 200 (OK) response to the I-CSCF indicating that Registration was successful. AS the 
URJ in the first path header field has an "ob" URI parameter, it include a Require header with the option-tag 
"outbound". 
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Table A.3.2-4: SIP 200 (OK) response (S-CSCF to l-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf l_p.homel.net , ■branch=z9hG4bK351g45 .1, SIP/2. 0/UDP 
pcscf 1 . visitedl -net ;branch=z9hG4bK24 0f 34 . 1 , SIP/2 . 0/UDP 
[5555 : :aaa:bbb: ccc :ddd] : 1357 ; comp=sigcomp ; branch=z9hG4bKnashds7 

Path: <sip : termopcscf 1 .visitedl .net; lr;ob> 

Service-Route : <sip : origOscscf 1 . homel . net ; lr> 

From: 

To: 

Call-ID: 

Contact: <sip: [5555 :: aaa :bbb : ccc :ddd] : 1357;comp=sigcomp>; 
pub-gruu=" sip: user l_publicl@homel .net ;gr=urn:uuid: f81d4fae-7dec-lld0-a765-00a0c91e6bf6" 
; temp-gruu="sip: tgruu. 7hs==jd7vnzga5w7fajsc7-ajd6f abzOf 8g5@example . com;gr" 
; +sip. instance="< urn:gsma: imei : 90420156-025763-0 >"+g. 3gpp . icsi-ref ="urn%3Aurn-7%3gpp- 
service . ims . icsi .mmtel" ; +g. 3gpp. ics= "principal" ; 
;expires=eOOOOO 

CSeq: 

Supported: path, outbound 

Require : outbound 

Date: Wed, 11 July 2001 08:49:37 GMT 

P-Associated-URI : <sip :userl_public2®homel .net>, <sip :userl_public3@homel .net>, <sip:+l-212- 
555-llll@homel .net ; user =phone> 

Content-Length : 



5-6. SIP 200 (OK) response (I-CSCF to UE) 

The I-CSCF forwards the SIP 200 (OK) response to the UE via P-CSCF#1. 

Editors" Note: The procedure of subscription to the registration-state event package is to be added. 

7. SIP REGISTER request (S-CSCF to SCC AS)-See example in table A.3.2-7 

After UE successfully registered in the IM CN subsystem, the S-CSCF sends a third party REGISTER request to 
the SCC AS based on the initial filter criteria it received. 

Table A.3.2-7: SIP REGISTER request (S-CSCF to SCC AS) 

REGISTER sip: sccas.homel.net /2.0 

Via: SIP/2. 0/UDP scscfl . homel . net ;branch=z9hG499ffhy 

Max-Forwards: 70 

From: <sip : scscfl .homel .net>; tag=538ya 

To : <sip : userl_publicl®homel . net> 

Call-ID: lasdaddlrf jflslj40a222 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Contact: <sip : scscfl .homel .net>; expires=600000 

CSeq: 87 REGISTER 

Content - Type : mult ipart /mixed ; boundary= " boundaryl " 

Content-Length: (...) 

--boundaryl 

Content-Type: message/sip 

REGISTER sip:registrar .homel .net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 .visitedl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2 . 0/UDP 
[5555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 69 

P-Access-Network-Info: 3GPP-UTRAN-TDD,- utran-cell-id-3gpp=234151D0FCEll 
Path: <sip: VskztcQ/S8p4WPbOnHbuyh5iJvJIW3ib®pcscf 1 .visitedl .net ; lr ;ob> 
Require: path 

P-Visited-Network-ID : "Visited Network Number 1" 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023 551024" 
From: <sip : 2 34150 999999999®ics .mnc015 .mcc2 34 . 3gppnetwork . org> ; tag=4f a3 
To: <sip:234150 999999999®ics .mnc015 .mcc2 34 . 3gppnetwork . org> 
From: <sip : userl_publicl®homel .net>; tag=4f a3 
To: <sip :userl_publicl®homel .net> 

Contact: <sip: [5555 :: aaa :bbb : ccc :ddd] : 1357 ; comp=sigcomp> ; reg-id=l,- +sip . instance="< 
urn:gsma : imei :90420156-025763-0>";+g. 3gpp . icsi-ref ="urn%3Aurn- 7%3gpp- 
service . ims . icsi .mmtel" ;+g. 3gpp . ics= "principal" ,-expires=600000 
Call -ID: apb0 3a0s0 9dkjdfglkj4 9111 

Authorization: Digest username="userl_private®homel .net" , realm="registrar .homel .net" , 
nonce=base64 {RAND + AUTN + server specific data), algorithm=AKAvl-MD5 , 
uri=" sip: registrar .homel .net" , response="6 62 9f ae4 93 93a0 5 3 974 5 978 50 7c4ef 1" 
CSeq: 2 REGISTER 
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Supported: path, outbound, gruu 
Content-Length: 

--boundaryl 

Content-Type: message/sip 

SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf l_p . homel . net ;branch=z9hG4bK351g45 . 1 , SIP/2. 0/UDP 
pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa :bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Path: <sip : termOpcscf 1 .visitedl .net; lr;ob> 
Service-Route : <sip : orig@scscf 1 . homel . net ; lr> 

From: <sip : 2 3415 9 9999 9999@ics .mnc015 .mcc234 . 3gppnetwork . org> ; tag=4f a3 
To: <sip: 234 15 9999999 99@ics .mnc015 .mcc234 . 3gppnetwork . org> 
Call -ID: apb03a0s0 9dkjdfglkj4 9111 

Contact: <sip: [5555: : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp> ; 
pub-gruu="sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-0 0a0c91e6bf 6" 
; temp -gruu=" sip : tgruu. 7hs==jd7vnzga5w7f aj sc7-ajd6f abzOf 8g5@example . com;gr" 
;+sip . instance="< urn:gsma : imei : 90420156-025763- 0>";+g. 3gpp . icsi-ref ="urn%3Aurn-7%3gpp- 
service . ims . icsi .mmtel" ;+g. 3gpp . ics= "principal" 
;expires=6 00000 
Supported: path, outbound 
Require : outbound 

Date: Wed, 11 July 2001 08:49:37 GMT 

P-Associated-URI : <sip :userl_public2@homel .net>, <sip :userl_public3®homel .net>, <sip: +1-212-555- 
llllohomel .net ,-user=phone> 
CSeq: 2 REGISTER 
Content-Length: 

--boundaryl-- 

8. SIP 200 OK response (SCC AS to S-CSCF) 

The SCC AS generates the SIP 200 (OK) response to the third party SIP REGISTER request. 

9. UE connects to a new IP-CAN 

The UE connects to a new IP-C/VN and will perform the registration via the new IP -CAN. 

10. SIP REGISTER request (UE to P-CSCF#2)- See example in table A.3.2-10 

UE sends the unprotected SIP REGISTER request via the new IP -CAN to P-CSCFh-2 which in this example is a 
different one with previous registration. 

Table A.3.2-10: SIP REGISTER request (UE to P-CSCF#2) 



REGISTER sip:registrar .homel .net SIP/2.0 

Via: SIP/2. 0/UDP [5555: : aaa :bbb : ccc : eee] ; comp=sigcomp;branch=z9hG4bKnasiuen8 

Max- Forwards : 70 

P-Access-Network-Info: IEEE-802 . lib 

From: <sip :userl_publicl@homel .net>,- tag=2hiue 

To: <sip :userl_publicl@homel .net> 

Contact: <sip : [5555 :: aaa :bbb : ccc : eee] ;comp=sigcomp>; reg-id=2; +sip . instance = "< 

urn:gsma: imei : 90420156-025763 -0>;+g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- 

service . ims .icsi .mmtel" ; +g. 3gpp. ics= "principal" ;expires=600000 
Call-ID: E05133BD26DD 
Authorization: Digest username="userl_private@homel .net" , realm="registrar .homel .net" , 

nonce="", uri="sip: registrar .homel .net " , response="" 
Security-Client: ipsec-3gpp; alg=hmac-sha-l-96 ; spi-c=23456789; spi-s=12345678 ; port-c=1234 ; 

port-s=5678 
Require: sec-agree 
Proxy-Require: sec-agree 
CSeq: 1 REGISTER 
Supported: path, outbound, gruu 
Content-Length: 



11-12. SIP REGISTER request (P-CSCF#2 to S-CSCF) 

The P-CSCF forwards the SIP REGISTER request towards S-CSCF via I-CSCF. Likewise in message #2, P- 
CSCF#2 adds a Path header with flow token and 'ob' parameter. 

13-15. SIP 401 (Unauthorized) response (S-CSCF to UE) 
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The authentication challenge is sent in the SIP 401 (Unauthorized) response towards the UE. 
16-18. SIP REGISTER request (UE to S-CSCF) 

The UE sends the protected SIP REGISTER request towards S-CSCF using contact#2. 
19-21. SIP 200 (OK) response (S-CSCF to UE) 

The S-CSCF sends a SIP 200 (OK) response towards the UE indicating that registration was successful. 
Editors" Note: The procedure of subscription to the registration-state event package is to be added. 

22. SIP REGISTER request (S-CSCF to SCC AS) 

The S-CSCF sends a third party REGISTER request to the SCC AS based on the initial filter criteria it received. 

23. SIP 200 (OK) response (SCC AS to S-CSCF) 

The SCC AS generates the SIP 200 response to the third party REGISTER request. 

A.4 Signalling flows for call origination 
A.4.1 Session origination for CS calls 

An example flow for session origination for CS calls can be found in 3GPP TS 24.292 [4]. 

A.5 Signalling flows for call termination 
A. 5.1 Session termination using CS media 

An example flow for session termination using CS calls can be found in TS 3GPP 24.292 [4]. 

A.6 Signalling flows for PS-CS session continuity 
A.6. 1 PS-CS access transfer: CS-PS 

In this example, SC UE A has an ongoing session with remote UE B over CS bearer before access transfer. When SC 
UE connects to an IP-CAN, it decides to transfer the session over the new IP-CAN. 
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Figure A.6.1-1 : Signalling flow for PS-CS Access Transfer: CS to PS 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. SC UE A has an ongoing session with remote UE B 

The call has been anchored at the SCC AS which is in the HPLMN of originating SC UE A. 

2. SC UE A connects to a new IP-CAN: 

The SC UE A decides to transfer the session over the new IP -CAN. The UE A obtains an IP address that it will 
use for the signalling and media. It registers with the S-CSCF over the new IP-CAN using standard registration 
procedure and reserves resources in the new IP-CAN. 

3. SIP INVITE request (SC UE A to intermediate IM CN subsystem entities) - see example in table A.6.1-3 

The SC UE A sends an initial INVITE request to request the new call replaces the existing call. 



£75/ 



3GPP TS 24.237 version 8.1 .0 Release 8 33 ETSI TS 1 24 237 V8.1 .0 (2009-03) 

Table A.6.1-3: SIP INVITE request (UE A to intermediate IM CN subsystem entities) 



INVITE sip : domain. xf erOsccas .homel .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route: <sip :pcscfl .homel .net : 7531; Ir >, <sip :orig@scscfl .homel .net ; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: IEEE-802 . lib 

Privacy: none 

From: <sip :userl_publicl®homel .net>; tag=171828 

To: <tel:+l-237-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj4 902 3 7 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 

Require: sec-agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321; portl=7531 

Contact : <sip :userl_publicl@homel .net ;gr= urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6>; +g. 3gpp. icsi-ref ="urn%3Aurn-7%3gpp- 
service . ims . icsi .mmtel" ; +g. 3gpp. ics= "principal" ; 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Accept: application/sdp; application/3gpp-ims+xml 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode- change -period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 



4. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

5. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 

The SIP INVITE request is forwarded to the SCC AS as the result of the evaluation of iFC. 

6. Remote Leg Update 

The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the Remote Leg. 

7. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities)- See example in table A.6.1-7 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID headers from one side of the B2BUA to the other. In this example the SCC AS includes 
the contents of the Contact header from the received SIP INVITE request. The SIP re-INVITE request contains 
the SDP offer that is identical to the SDP offer that the SCC AS received in the initial SIP INVITE request from 
the UE A (Step 3). 
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Table A.6.1-7: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE < sip:userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-0 0a0c91e6bf 6> SIP/2 . 
Via: SIP/2. 0/UDP sccas.homel.net; branch=z9hG4bK332b33 . 3 ; 
Max-Forwards: 67 

Route: <scscf 1 .homel .net ; Ir >, <sip : scscf 2 .home2 .net ; lr>, <sip :pcscf 2 . visited2 .net ; lr> 
P-Asserted-Identity : "John Doe" <sip :userl_publicl@homel .net>, <tel : +l-237-555-llll> 
P-Access-Network-Info: IEEE-802 . lib 
Privacy: none 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" 
P-Charging-Function-Addresses : 

From: <sip :userl_publicl@homel .net>; tag=1717777 
To: <tel:+l-237-555-2222>, tag=4321 
Call -ID: dcl4bltl0b3teghmlk50132 3 7 
Cseq: 111 INVITE 
Supported: precondition, lOOrel 

Contact : <sip:user2_publicl@home2 .net ;gr=urn:uuid: 2ad8950e-4 8a5-4a74-8d99- 
ad76cc7f c74>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 



8. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B) 

The intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE B. 
9-10: SIP 200 (OK) response (UE B to SCC AS via Intermediate IM CN subsystem entities) 

The UE B generates the SIP 200 (OK) response to the SIP re-INVITE request and forwards it to the SCC AS. 
11-12: SIP ACK request (SCC AS to UE B via Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the remote UE B. 
13-14: SIP 200 (OK) response (SCC AS to UE A via Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request and forwards it to the SC UE A. 
15-16: SIP ACK request (SC UE A to SCC AS via Intermediate IM CN subsystem entities) 

The SC UE A generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the SCC AS 
17. Media paths between UE A and UE B 

The media path is using the new IP-CAN. 
18-19. SIP BYE request (SCC AS to interworking entities via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the CS bearer, by sending a BYE request. 
20-22. ISUP Message 

Upon receiving the DISCONNECT request, the SC UE A relinquishes all resources pertaining to the CS bearer. 
23-24. SIP 200 (OK) response (Interworking entities to SCC AS via intermediate IM CN subsystem entities) 
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A.6.2 PS-CS access transfer: PS-CS 

In this example, SC UE A has an ongoing session with remote UE B over PS bearer before access transfer which is 
anchored at SCC AS. When the SC UE attaches to the CS domain, it decides to transfer the session over the CS bearer 
without ICS capabiUty. 
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Figure A.6.2-1 Signalling flow for PS-CS access transfer: PS-CS 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. SC UE A is on an active session with UE B: 

There is an ongoing IP bearer between the SC UE and the remote end UE B. The call is achored at SCC AS. 

2. SC UE A attaches to the CS domain 

The SC UE attaches to the CS domain and decides to transfer the session over the CS bearer. 

3. CC SETUP messages 
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The SC UE sends the CS SETUP message with the static STN as the called party number. 

4. SIP INVITE request (Interworking entities to Intermediate IM CN subsystem entities) -see example in 
Table A.6.2-4 

Table A.6.2-4: SIP INVITE request (interworking entities to intermediate IM CN subsystem entities) 



INVITE tel: +1-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mgcfl.homel.net;branch=z9hG4bk731b87 

Max- Forwards : 7 

Route : <sip : icscf 1 . homel . net ; lr> 

P-Asserted-Identity: <tel: +l-237-555-llll> 

P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 

Privacy: none 

From: <tel: +l-237-555-llll>; tag=171828 

To: <tel: +l-237-555-3333> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: lOOrel, precondition 

Accept -Contact : * ; +g. 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 

P- Asserted- Service : urn: urn- 7 : 3gpp- service . ims .icsi .mmtel 

Contact : <sip :mgcf 1 .homel .net ;gr>; +g. 3gpp . icsi -ref="urn%3Aurn-7%3gpp- service . ims .icsi .mmtel" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

t = 

m=audio 3456 RTP/AVP 97 96 

a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 2 



Request-URI: contains the IMRN, as obtained from CS networks signalling. 
SDP: The SDP contains preconfigured set of codecs supported by the MGW. 

5. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

6. SIP INVITE request (Intermediate IM CN subsystem entities to SCC AS) 

7. Remote Leg Update 

The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the Remote Leg. 

8. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) -see example in table A.6.2- 
8 

The SCC AS acting as a routing B2BUA generates a SIP INVITE request based upon the received SIP INVITE 
request and the information previously stored against this session and routes it towards UE B via the 
intermediate IM CN subsystem entities. 
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Table A.6.2-8: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE sip:user2_publicl®home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74 SIP/2 . 

Via: SIP/2. 0/UDP sccasl . homel . net ;branch=z9hG4bKnas34r5 

Max-Forwards: S7 

Route: <sip : scscfl .homel .net : lr> 

P-Asserted-Identity: <tel: +l-237-555-llll> 

P- Charging- Function- Addresses : ccf = [5555: :b99:c88:d7 7:e66] ; ccf= [5555: :a55 :b44 :c3 3 :d22] ; 
ecf= [5555: : If f : 2ee : 3dd: 4ee] ; ecf= [5555: : 6aa : 7bb : 8cc : 9dd] 

P-Charging-Vector : icid-value="BzyretyU0dm+6O2IrT5tAFrbHLso=023551034" ; orig- 
ioi="type3homel .net" 

Privacy: none 

From: <tel: +l-237-555-llll>; tag=569812 

To: <tel:+l-237-555-2222>; tag=26545 

Call -ID: ddl3aOs0 9a2sdfglkj 490378 

Cseq: 

Contact : <sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 

Allow: 

Content-Type: Content-Length: 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

t=0 

m=audio 3456 RTP/AVPF 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode- change -period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 

m=message TCP/MSRP 98 

a=accept-types : text/plain 



9. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B) 

Intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE B. 

10. SIP 200 (OK) response (UE B to intermediate IM CN subsystem entities) 

Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE B has all resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

11. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SIP re-INVITE request to 
the SCC AS in the originating network. 

12-13. SIP ACK request (SCC AS to UE B via IM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request 
to the remote UE B. 

14-15. SIP 200 (OK) response (SCC AS to interworking entities via IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request, and forwards the SIP 200 (OK) 
response to the interworking entities. 

16. ISUP CONNECT message (interworking entities to SC UE A) 

17. ISUP CONNECT Response message (SC UE A to interworking entities) 

18-19. SIP ACK request (interworking entities to SCC AS via IM CN subsystem entities) 
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The interworking entities generate the SIP ACK request to the SIP 200 (OK) response, and forward it to the SCC 
AS. 

20. Media paths between SC UE A and UE B: 

The CS bearer is setup while the PS bearer is still existing. 

21-22: SIP BYE request (SCC AS to SC UE A via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the old IP -CAN, by sending a BYE request to the 
UEA. 

23-24. SIP 200 (OK) response (SC UE A to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the BYE request over the old IP -CAN, the SC UE A sends a SIP 200 (OK) response over the old 
IP-CAN to the SCC AS. Subsequently, the SC UE A relinquishes all resources pertaining to the old IP -CAN. 

25. Media paths between SC UE A and UE B 

Finally, the session is transferred from PS bearer to CS bearer. 



A.7 Signalling flows for PS-PS session continuity 
A. 7.1 Introduction 

The signalling flows for PS-PS access transfer demonstrate how a multimedia session is transferred from Source Access 
Leg to the Target Access Leg. The following signalling flows are included: 

subclause A. 7. 2 shows an example when all media of an ongoing communication session and the associated 
signalling are transferred from Source Access Leg to the Target Access Leg; and 

subclause A.7. 3 shows an example when not all media of an ongoing communication session are transferred 
from the Source Access Leg to the Target Access Leg. 

A. 7. 2 PS-PS access transfer with full media transfer 

The signalling flows shown in figure A.7. 2-1 describes the PS-PS access transfer procedure when all media of an 
ongoing communication session and the associated signalling are transferred from one contact address of an UE to a 
different contact address of the same UE. No lower-level mechanism to support the session continuity is assumed or 
need. 

In this example the UE-1 is on an active multimedia session with the UE-2 via one IP-CAN. After changing to a new 
IP-CAN, obtaining a new IP address, and discovering a P-CSCF, the UE-1 reserves resources in new IP -CAN prior to 
initiating the PS-PS access transfer procedure. When the PS-PS access transfer procedure is completed, the UE-1 
continues the multimedia session with the UE-2 on the new IP -CAN. In this example, when attaching to the new IP- 
CAN, it is irrelevant whether the UE-1 uses the same P-CSCF or a new P-CSCF. 

NOTE 1: This scenario requires that the UE-1 and the IMS network support simultaneous multiple registrations and 
requires that the UE-1 supports dual mode operation. 

NOTE 2: In this example flow, each call leg is uniquely identified with a respective dialog identifier consisting of 
the Call-ID, From tag, and To tag. 
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Figure A.7.2-1 : Signalling flow for session handover 

NOTE 3: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. UE-1 is on an active session with UE-2 

The UE-1 is in an active session with the UE-2. The call is anchored in the SCC AS. It is irrelevant which 
endpoint initiated the call. Each call leg is uniquely identified with a respective dialog identifier. The call lej 
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over old IP-CAN is identified with "Call-ID= me03a0s09a2sdfgjkl491777", "From tag=64727891", and "To 
tag=77432r'. The UE-1 and UE-2 exchange media over the old IP-CAN, which is maintained while the UE-1 
initiates the handover procedure. 

2. UE-1 connects to new IP-CAN 

The UE-1 determines that a handover of the session is required. The UE-1 connects to the new IP-CAN. The 
UE- 1 obtains an IP address that it will use for the signalling and media. 

3. UE-1 registers with intermediate IM CN subsystem entities over new IP-CAN 

The UE-1 registers with the S-CSCF over the new IP-CAN using the standard registration procedure. Depending 
on the UE-1 configuration, the discovery of the P-CSCF in the new IP-CAN may be needed. 

4. UE-1 acquires resources in new IP-CAN 

Based on the UE-1 and new IP -CAN capabilities, the UE-1 decides to use the same codec that was used over the 
old IP -CAN. The UE-1 reserves resources (e.g. QoS) in the new IP -CAN that will be needed for the signalling 
and transferred media, prior to sending the initial SIP INVITE request. 

5. SIP INVITE request (UE-1 to intermediate IM CN subsystem entities) - see example in table A.7.2-5 

The UE-1 sends initial SIP INVITE request with a new SDP offer to the UE-2 that indicates that the new call 
replaces the existing call. The initial SIP INVITE request establishes a dialog for signalling and specifies in the 
SDP the new contact address that will be used for media over the new IP-CAN. Upon sending the initial SIP 
INVITE request, the UE-1 is ready to receive the RTP packets either over the new IP -CAN or the old IP-CAN. 
The RTP packets may arrive over the new IP-CAN prior to the UE-1 receiving the SIP 200 (OK) response for 
the initial SIP INVITE request. 

Table A.7.2-5: SIP INVITE request (UE-1 to intermediate IM CN subsystem entities) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 70 

Route : <sip ipcscf 1 .homel .net : 75 31; lr;comp=sigcomp>, <sip lorigOscscf 1 .homel .net; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl®homel .net> 

P-Access-Network-Info: IEEE-802 . lib 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=171828 

To: <tel:+l-212-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj49033 3 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 

Require: sec-agree; replaces 

Replaces: me03aOs09a2sdfgjkl491777; to-tag=774321; f rom-tag=64727891 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321; portl=7531 

Contact : <sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6>; +g. 3gpp. icsi-ref ="urn%3Aurn-7%3gpp- 
service . ims . icsi .mmtel" ; +g. 3gpp. ics= "principal" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Accept: application/sdp; application/3gpp-ims+xml 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 
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Request-URI: the tel-URI of the destination, i.e. the UE-2. 

Require: the "replaces" option tag indicate that the support for Replace header is required. 

Replaces: specifies the existing call that will be replaced with the new call. 

SDP: specifies the new IP address that the UE-1 has acquired in the new IP-CAN, and indicates that the 
resources in the new IP -CAN have been acquired. 

6. Evaluation of initial filter criteria 

Upon the evaluation of the initial filter criteria, as this is an originating initial SIP INVITE request for a 
registered user, the S-CSCF routes the initial SIP INVITE request to the SCC AS. 

7. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) - see example in table A.7.2-7 

The initial INVITE request is forwarded from intermediate IM CN subsystem entities in the home network to the 
SCC AS. The SCC AS acts as a routeing B2BUA as specified in 3GPP TS 24.229 [2]. In this example the SCC 
AS includes the contents of the Contact header from the received SIP INVITE request. 

Table A.7.2-7: SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2 . 0/UDP 

pcscf 1 .homel .net ;branch=z9hG4bK24 0f 34 .1, SIP/2 . 0/UDP 
[5555 : :aaa:bbb: ccc :ddd] : 13 5 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 
Max-Forwards: 67 
Route: <sip : sccas .homel .net ; lr> 

Record- Route : <sip:scscfl .homel .net; lr>, <sip:pcscfl .homel .net; lr> 

P-Asserted-Identity : "John Doe" <sip :userl_publicl®homel .net>, <tel : +l-212-555-llll> 
P- Access -Network- Info : Privacy : Require : replaces 
P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ;orig- 

ioi=type3ashomel .net> 
P- Charging- Function-Addresses : ccf = [5555 : :b99 : c88 :d77 : e66] ; ccf = [5555 : : a55 :b44 : c3 3 :d22] 

ecf= [5555: : If f : 2ee : 3dd: 4ee] ; ecf= [5555: : 6aa : 7bb : 8cc : 9dd] 
From: <sip :userl_publicl®homel .net>; tag=171828 
To: <tel:+l-212-555-2222> 
Call-ID: 
Cseq: 

Supported : Replaces : Contact : 
Allow: Accept : Content -Type : 
Content-Length: (...) 

v= 
o= 
s = 
c = 

t = 
m= 



8. Remote leg update 

The SCC AS based on the content of the Replaces header correlates the initial SIP INVITE request to the 
existing local and remote call legs of the existing concatenated end to end session between the UE-1 and UE-2. 
The SCC AS updates the remote call leg by sending a SIP re-INVITE request to the UE-2 containing the new 
SDP offer that it has received from the UE-1. 

9. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) - see example in table A.7.2-9 

The UE-2 is informed of the change in access leg by the SCC AS sending a SIP re-INVITE request to the S- 
CSCF. 
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The sec AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID headers from one side of the B2BUA to the other. In this example the SCC AS includes 
the contents of the Contact header from the received SIP INVITE request. The SIP re-INVITE request contains 
the SDP offer that is identical to the SDP offer that the SCC AS received in the initial SIP INVITE request from 
the UE-1 (Step 5). 

Table A.7.2-9: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE < sip:user2_publicl@home2 . net ;gr=urn : uuid : 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74> SIP/2 . 

Via: SIP/2. 0/UDP sccas.homel.net; branch=z9hG4bK332b33 . 3 ; 

Max-Forwards: 67 

Route : <scscf 1 .homel .net; lr>,<sip:scscf2 .home2 .net; lr>,<sip:pcscf2 . visited2 .net; lr> 

P-Asserted- Identity : P- Access -Network- Info : Privacy: P- Charging- Vector: icid- 
value="BzyretyU0dm+602IrT5tAFrbHLso=02 3 551034 " 

P-Charging-Function-Addresses : 

From: <sip :userl_publicl@homel .net>; tag=1717777 

To: <tel:+l-212-555-2222>, tag=4321 

Call-ID: dcl4bltl0b3teghmlk5013333 

Cseq: 111 INVITE 

Supported: 

Contact : < sip :userl_publicl@homel .net ;gr=urn: uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 

Allow: Accept: application/sdp 

Content-Type : 

Content-Length: (...) 

v=0 

0=2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = - 

c= IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a= curr:qos local sendrecv 

a= curr:qos remote none 

a= des:qos mandatory local sendrecv 

a= des:qos none remote sendrecv 

a= rtpmap:97 AMR 

a= fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a= rtpmap:96 telephone-event 

a= maxptime:20 



Route: The SIP re-INVITE request contains the saved list of Route headers that the SCC AS has saved for the 
remote leg of the call. 

10. SIP re-INVITE request (intermediate IM CN subsystem entities to intermediate IM CN subsystem 
entities) - see example in table A.7.2-10 

In the originating network, the intermediate IM CN subsystem entities forward the SIP re-INVITE request to the 
intermediate IM CN subsystem entities in the terminating network. 
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Table A.7.2-10: SIP re-INVITE request (intermediate IIVI CN subsystem entities to intermediate IM CN 

subsystem entities) 



INVITE < sip:user2_publicl@home2 .net ;gr=urn:uuid: 2ad895 0e-4 8a5-4a74-8d99-ad76cc7f c74> SIP/2 . 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP sccas.homel.net; 
branch=z9hG4bK332b33.3; 

Max-Forwards: 66 

Route : <sip:scscf2 .home2 .net; lr>, <sip:pcscf2 . visited2 .net; lr> 

P-Asserted- Identity : 

Privacy: none 

From: 

To: 

Call-ID: 

Cseq: Supported: Contact : <sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 

Allow: 

Accept : 

Content-TypeContent-Length : 

v= 

o= 

s=- 

c= 

t= 

m= 

b= 

a= 

a= 

a= 

a= 

a= 



11. SIP re-INVITE request (intermediate IM CN subsystem entities to UE-2) 

In the terminating network, the SIP re-INVITE request is forwarded towards the UE-2 by the intermediate IM 
CN subsystem entities. 

12. Media paths between UE-1 and UE-2 

The UE-2 receives the SIP re-INVITE request containing the SDP offer that indicates that the UE-1 is ready to 
receive the same media on a different contact address. Since the UE-2 has resources already available, it starts to 
send the media to the UE-l's contact address specified in the SDP offer immediately. 

The UE-1 will be receiving the RTP packets over new IP-CAN. However, the UE-1 can receive some out-of- 
sequence RTP packets over the old IP -CAN. The RTP packets are delivered to the codec in sequence. Once the 
UE-1 determine that no media will be received over the old IP-C/VN (e.g. by examining the sequence numbers in 
the RTP headers), it can relinquish the resources that it has been using for incoming media on the old IP -CAN. 

The UE-1 sends the media to the UE-2 over the old IP-CAN. 

Resources used for signalling on the old IP -CAN are not released. 

13. SIP 200 (OK) response (UE-2 to intermediate IM CN subsystem entities) 

Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE-2 has all resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

14. SIP 200 (OK) response (intermediate IM CN subsystem entities to intermediate IM CN subsystem entities) 

In the terminating network, the intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the 
SIP re-INVITE request to the intermediate IM CN subsystem entities in the originating network. 

15. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities in the originating network forward SIP the 200 (OK) response to the 
SIP re-INVITE request to the SCC AS. 



£75/ 



3GPP TS 24.237 version 8.1 .0 Release 8 44 ETSI TS 1 24 237 V8.1 .0 (2009-03) 

16. SIP ACK request (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS acting as a B2BUA acknowledges the receipt of the SIP 200 (OK) response to the SIP re-INVITE 
request by forwards a SIP ACK request to the intermediate IM CN subsystem entities. 

17. SIP ACK request (intermediate IM CN subsystem entities to intermediate IM CN subsystem entities) 

In the originating network, the intermediate IM CN subsystem entities forward the SIP ACK request to the 
intermediate IM CN subsystem entities in the terminating network. 

18. SIP ACK request (intermediate IM CN subsystem entities to UE-2) 

In the terminating network, the intermediate IM CN subsystem entities forward the SIP ACK request to the UE- 

2. 

19. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS forwards the SIP 200 (OK) response to the initial SIP INVITE request to the intermediate IM CN 
subsystem entities, using the content of the Via header that was received in the initial INVITE request (step 5). 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID headers from one side of the B2BUA to the other. The SIP 200 (OK) response to the initial 
SIP INVITE request contains the SDP answer that is identical to the SDP answer that the SCC AS has received 
in the SIP 200 (OK) response to SIP re-INVITE request from the UE-2 (Step 13). 

20. SIP 200 (OK) response (intermediate IM CN subsystem entities to UE-1) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the UE-1. 

21. Media paths between UE-1 and UE-2 

The UE-1 receives the SIP 200 (OK) response containing the SDP answer that indicates that the UE-2 is ready to 
receive media. Since the UE-1 has already resources available, it starts to send media over new IP -CAN to the 
UE-2's contact address specified in the SDP answer immediately. 

The UE-1 may relinquish the resources that it has been using for outgoing media on the old IP-CAN. 

Resources used for signalling on the old IP -CAN are not released. 

22. SIP ACK request (UE-1 to intermediate IM CN subsystem entities) 

The UE-1 completes the new call leg creation with a SIP ACK request sent to the intermediate IM CN subsystem 
entities. 

23. SIP ACK request (-intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the SCC AS. 

24. SIP BYE request (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg- that was using the old IP-CAN, by sending a SIP BYE request to 
the UE-1. 

25. SIP BYE request (intermediate IM CN subsystem entities to UE-1) 

The intermediate IM CN subsystem entities forward the BYE request to the UE-1. 

26. SIP 200 (OK) response (UE-1 to intermediate IM CN subsystem entities) 

Upon receiving the SIP BYE request over the old IP-CAN, the UE-1 sends a SIP 200 (OK) response over the old 
IP-CAN. Subsequently, the UE-1 relinquishes all resources pertaining to the old IP-CAN. 

27. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SCC AS. 
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A. 7. 3 PS-PS access transfer with partial media transfer 

The signalling flows shown in figure A.7.3-1 describes the PS-PS access transfer procedure when not all media of an 
ongoing communication session are transferred from the Source Access Leg to the Target Access Leg. No lower-level 
mechanism to support the session continuity is assumed or needed. 

In this example, UE-1 is on an active multimedia session with UE-2 via one IP-CAN. After connecting to an additional 
IP -CAN, obtaining an additional IP address, discovering a P-CSCF, and performing IMS registration, UE-1 reserves 
resources in the new IP-CAN prior to initiating the PS-PS access transfer procedure. When the PS-PS access transfer 
procedure is completed, UE-1 continues the multimedia session with UE-2 on both the old and the new IP-CANs. In 
this example, when attaching to the new IP -CAN, it is irrelevant whether the UE-1 uses the same P-CSCF or a new 
P-CSCF. 

NOTE 1: This scenario requires that UE-1 and the IMS network support simultaneous multiple registrations and 
requires that UE-1 supports dual mode operation. 
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Figure A.7.3-1 : Signalling flow for PS-PS session transfer with partial media transfer 

NOTE 2: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

1. UE-1 is on an active session with UE-2 

UE-1 is in an active session with UE-2. The call is anchored in the SCC AS. It is irrelevant which endpoint 
initiated the call. Each call leg is uniquely identified with a respective dialog identifier. The call leg over IP- 
CAN #1 is identified with "Call-ID= me03a0s09a2sdfgjkl491777", "From tag=64727891", and "To 
tag=77432r'. UE-1 and UE-2 exchange media over the IP -CAN #1, which is maintained while the UE-1 initiates 
the session transfer procedure. 

2. UE-1 connects to IP-CAN #2 
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UE-1 connects to the new IP-CAN and obtains an IP address that it will use for the signalling and media. 

3. UE-1 registers with intermediate IM CN subsystem entities over IP-CAN #2 

UE-1 registers with the S-CSCF over the IP -CAN #2 using the standard registration procedure. The P-CSCF in 
the signalling path of this registration may be distinct from the one used in the signalling path over IP-CAN #1. 

4. UE-1 acquires resources in IP-CAN #2 

UE-1 decides to perform partial media transfer to the IP-CAN #2. Based on UE-1 and IP -CAN #2 capabilities, 
the UE-1 decides to use the same codec that was used over the IP -CAN #1 for the media components to be 
transferred. UE-1 ensures that the resources (e.g. QoS) in IP -CAN #2 that will be needed for the signalling and 
transferred media are available, prior to sending the initial SIP INVITE request. 

5. SIP INVITE request (UE-1 to intermediate IM CN subsystem entities) - see example in table A.7.3-5 

UE-1 sends initial SIP INVITE request with a new SDP offer to UE-2 and indicates that the video component is 
to be transferred to IP -CAN #2. The initial SIP INVITE request establishes a dialog for signalling and specifies 
in the SDP new contact address that will be used for media over IP -CAN #2. Upon sending the initial SIP 
INVITE request, UE-1 is ready to receive the RTP packets over both IP-CAN #1 and IP -CAN #2. 

Table A.7.3-5: SIP INVITE request (UE-1 to intermediate IM CN subsystem entities) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : sip :pcscf 1 .homel .net : 75 31; Ir ; comp=sigcomp> , <sip :orig@scscf 1 .homel .net ; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: IEEE-802 . lib 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=171828 

To: <tel:+l-212-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj4903 3 3 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 

Require: sec-agree; tdialog 

Target-Dialog: me03a0s09a2sdf gjkl491777 ; remote-tag=774321; local-tag=64727891 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321; portl=7531 

Contact : < sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6>; +g. 3gpp. icsi-ref ="urn%3Aurn-7%3gpp- 
service . ims . icsi .mmtel" ; +g. 3gpp. ics= "principal" ; 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Accept: application/sdp; application/3gpp-ims+xml 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = - 

c = IN IP6 5555 : :aaa:bbb:ccc :ddd 

t = 

m=audio RTP/AVP 97 96 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode- change -period=2 

a=rtpmap:96 telephone-event 

m=video 3400 RTP/AVP 98 99 

b=AS:75 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



Request-URI: the tel-URI of the destination, i.e. the UE-2. 

Require: the "tdialog" option tag indicate that the support for Target-Dialog header is required. 

Target-Dialog: specifies the existing call that will be transferred. 
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SDP: specifies the new IP address that the UE-1 has acquired in the new IP-CAN, and indicates that only the 
video component will be transferred and the resources in the new IP-CAN have been reserved. 

6. Evaluation of initial filter criteria 

Upon the evaluation of the initial filter criteria, as this is an originating initial SIP INVITE request for a 
registered user, the S-CSCF routes the initial SIP INVITE request to the SCC AS. 

7. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 

The initial SIP INVITE request is forwarded from intermediate IM CN subsystem entities in the home network 
to the SCC AS. The SCC AS acts as a routeing B2BUA as specified in 3GPP TS 24.229 [2]. 

8. Remote leg update 

Based on the content of the Target-Dialog header, the SCC AS correlates the SIP INVITE request for session 
transfer to the existing local and remote call legs of the existing concatenated end to end session between UE-1 
and UE-2. The SCC AS updates the remote call leg by sending a SIP re-INVITE request to the UE-2 containing 
the new SDP offer based on the partial media transfer request received from UE-1 and the negotiated SDP for 
the original session. 

9. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) - see example in table A.7.3-9 

UE-2 is informed of the change in access leg by the SCC AS sending a re-INVITE request to the S-CSCF. 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID headers from one side of the B2BUA to the other. In this example the SCC AS includes 
the contents of the Contact header from the received SIP INVITE request. The SIP re-INVITE request contains 
the SDP offer that is based on original SDP offer and the SDP offer that the SCC AS received in the initial SIP 
INVITE request from the UE-1 (Step 7). 
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Table A.7.3-9: SIP re-INVITE request (SCC AS to Intermediate IM CN subsystem entitles) 



INVITE < sip:user2_publicl®home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74> SIP/2 . 0> 
Via: SIP/2. 0/UDP sccas.homel.net; branch=z9hG4bK332b33 . 3 ; 
Max-Forwards: 70 

Route: <scscf 1 .homel .net ; lr>, <sip : scscf 2 .home2 .net ; lr>, <sip :pcscf 2 . visited2 .net ; lr> 
P-Asserted-Identity : "John Doe" <sip :userl_publicl@homel .net>, <tel : +l-212-555-llll> 
Privacy: none 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" 
P-Charging-Function-Addresses : 

From: <sip:userl_publicl@homel .net>; tag=1717777 
To: <tel:+l-212-555-2222>, tag=4321 
Call -ID: dcl4bltl0b3teghmlk50 13333 
Cseq: 111 INVITE 
Supported: precondition, lOOrel 

Contact : <sip :userl_publicl®homel .net; gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

= 2987933100 2987933101 IN IP6 5555 : : aaa :bbb : ccc : eee 

s = - 

t = 

m=audio 3456 RTP/AVP 97 96 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

b=AS:25 .4 

a= curr:qos local sendrecv 

a= curr:qos remote none 

a= des:qos mandatory local sendrecv 

a= des:qos none remote sendrecv 

a= rtpmap:97 AMR 

a= fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a= rtpmap:96 telephone-event 

a= maxptime:20 

m=video 3400 RTP/AVP 98 99 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

b=AS:75 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



Route: The SIP re-INVITE request contains the saved list of Route headers that the SCC AS has saved for the 
remote leg of the call. 

SDP: specifies the new IP address and ports used for the media components. In this case, the audio component is 
still using the original address and port while the video component is using the new IP address and new port 
allocated. 

10. SIP re-INVITE request (intermediate IM CN subsystem entities to intermediate IM CN subsystem 
entities) 

In the originating network, the intermediate IM CN subsystem entities forward the SIP re-INVITE request to the 
intermediate IM CN subsystem entities in the terminating network. 

11. SIP re-INVITE request (intermediate IM CN subsystem entities to UE-2) 

In the terminating network, the SIP re-INVITE request is forwarded towards UE-2 by the intermediate IM CN 

subsystem entities. 

UE-2 receives the SIP re-INVITE request containing the SDP offer that indicates that UE-1 is ready to receive 
video media on a different contact address. Since UE-2 has resources already available, it starts to send the 
media to UE-l's contact address specified in the SDP offer immediately. 

UE-1 starts receiving the video RTP packets over IP-CAN #2. However, UE-1 may receive some out-of- 
sequence video RTP packets over IP -CAN #1. The video RTP packets are delivered to the codec in sequence. 
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Once UE-1 determine that no video will be received over IP-CAN #1 (e.g. by examining the sequence numbers 
in the RTP headers), it may relinquish the resources that it has been using for incoming video media on IP-CAN 
#1. 

At the same time, UE-1 still sends both the audio and video media to UE-2 over IP -CAN #1. 

Resources used for signalling on IP -CAN #1 are not released. 

12. SIP 200 (OK) response (UE-2 to intermediate IM CN subsystem entities) - see example in table A.7.3-12 

Upon receiving the SIP re-INVITE request containing the SDP offer, since UE-2 has all resources available, it 
sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

Table A.7.3-12: SIP 200 (OK) response (UE-2 to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2 . 0/UDP pcscf2 .visited2 .net : 50 8 8 ;comp=sigcomp;branch=z9hG4bK3 61k21 . 1, 
SIP/2 .0/UDP scscf2 .home2 .net ;branch=z9hG4bK764z87 . 1 , 
SIP/2 .0/UDP scscfl.homel.net;branch=z9hG4bK3 3 2b2 3 .1, 
SIP/2 .0/UDP sccas.homel.net;branch=z9hG4bK3 3 2b3 3 .3 

Record- Route : <sip :pcscf 2 . visited2 .net : 5 088 ; lr;comp=sigcomp>, <sip:scscf2 .home2 .net ; lr>, 
<sip:scscfl .homel .net ; lr> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=1717777 

To: <tel:+l-212-555-2222>;tag=4 321 

Call -ID: dcl4bltl0b3teghmlk5 013333 

CSeq: 111 INVITE 

Supported: precondition, lOOrel 

Contact : <sip:user2_publicl@home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99- 
ad76cc7f c74>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" > 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933623 2987933624 IN IP6 5555 : : eee : f f f : aaa : bbb 

s = - 

c = IN IP6 5555 : :eee:fff :aaa:bbb 

t = 

m=audio 6544 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode- change -period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 

m=video 10001 RTP/AVP 98 99 

b=AS:75 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



13. SIP 200 (OK) response (intermediate IM CN subsystem entities to intermediate IM CN subsystem 
entities) 

In the terminating network, the intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the 
SIP re-INVITE request to the intermediate IM CN subsystem entities in the originating network. 

14. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities in the originating network forward the SIP 200 (OK) response to the 
SIP re-INVITE request to the SCC AS. 
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15. SIP ACK request (SCC AS to intermediate IM CN subsystem entities) 

The SCC AS acting as a B2BUA acknowledges the receipt of the SIP 200 (OK) response to the SIP re-INVITE 
request by forwards a SIP ACK request to the intermediate IM CN subsystem entities. 

16. SIP ACK request (intermediate IM CN subsystem entities to intermediate IM CN subsystem entities) 

In the originating network, the intermediate IM CN subsystem entities forward the SIP ACK request to the 
intermediate IM CN subsystem entities in the terminating network. 

17. SIP ACK request (intermediate IM CN subsystem entities to UE-2) 

In the terminating network, the intermediate IM CN subsystem entities forward the SIP ACK request to UE-2. 

18. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) - see example in table A.7.3- 
18 

The SCC AS forwards the SIP 200 (OK) response to the initial SIP INVITE request to the intermediate IM CN 
subsystem entities, using the content of the Via header that was received in the initial SIP INVITE request (step 

5). 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID headers from one side of the B2BUA to the other. In this example the SCC AS includes 
the contents of the Contact header from the received SIP 200 (OK) response. The SIP 200 (OK) response to the 
initial SIP INVITE request contains the SDP answer derived from the SDP answer that the SCC AS has received 
in the SIP 200 (OK) response to SIP re-INVITE request from UE-2 (Step 14). 

Table A.7.3-18: SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , 
SIP/2 . 0/UDP pcscfl .homel .net;branch=z9hG4bK240f 34 .1, 
SIP/2 . 0/UDP [5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Record- Route : <sip:sccas .homel .net; lr>,<sip:scscfl .homel .net; lr>, <sip: pcscfl .homel .net ; lr> 

Privacy: none 

From: <sip : userl_publicl@homel . net> ; tag=171828 

To: <tel: +1-212- 555-2222 >;tag=8009 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: 10 Orel; precondition 

Contact : < sip:User2_publicl@home2 .net ;gr=urn:uuid: 2ad8950e-4 8a5-4a74-8d99- 
ad76cc7f c74>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Accept: application/sdp; 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933300 2987933300 IN IPS 5555 :: eee : fff : aaa :bbb 

s = - 

c = IN IP6 5555 : :eee:fff :aaa:bbb 

t = 

m=audio RTP/AVP 97 96 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a = r tpmap :96 telephone- event 

m=video 10001 RTP/AVP 98 99 

b=AS:75 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



19. SIP 200 (OK) response (intermediate IM CN subsystem entities to UE-1) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to UE-1. 
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UE-1 receives the SIP 200 (OK) response containing the SDP answer indicating that UE-2 is ready to receive 
media. Since UE-1 has already resources available, it starts to send video media over IP-CAN #2 to UE-2's 
contact address specified in the SDP answer immediately. 

The UE-1 may relinquish the resources that it has been using for outgoing video media on IP-CAN #1. 

Resources used for signalling and audio media on IP-CAN #1 are not released. 

20. SIP ACK request (UE-1 to intermediate IM CN subsystem entities) 

UE-1 completes the new call leg creation with a SIP ACK request sent to the intermediate IM CN subsystem 
entities. 

21. SIP ACK request ( intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the SCC AS. 

22. SIP re-INVITE request (UE-1 to intermediate IM CN subsystem entities) - see example in table A.7.3-22 

UE-1 updates the old call leg on IP -CAN #1 by sending a SIP re-INVITE request to the intermediate IM CN 
subsystem entities. 

Table A.7.3-22: SIP re-INVITE request (UE-1 to intermediate IM CN subsystem entities) 



INVITE <sip:user2_publicl@home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74> SIP/2 . 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : eee] : 2468 ; comp=sigcomp;branch=z9hG4bKashdnsl 

Max-Forwards: 70 

Route : sip :pcscf 1 .homel .net : 8 76 5 ; lr;comp=sigcomp>, <sip :orig@scscf 1 .homel .net; lr> 

P-Access-Network-Info: 3GPP-UTRAN-FDD; utran-cell-id-3gpp=123456ABCDE22 

Privacy: none 

From: <sip :userl_publicl®homel .net>; tag=64727891 

To: <tel:+l-212-555-2222>; tag=774321 

Call -ID: me0 3a0s0 9a2sdfgjkl4 91777 

Cseq: 101 INVITE 

Supported: lOOrel; precondition; tdialog 

Require: sec-agree; 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=12345678 ; portl=2468 

Contact : <sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6>; +g. 3gpp. icsi-ref ="urn%3Aurn-7%3gpp- 
service . ims . icsi .mmtel" ; +g. 3gpp. ics= "principal" ; 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Accept: application/sdp; application/3gpp-ims+xml 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933000 2987933001 IN IP6 5555 :: aaa :bbb : ccc : eee 

s = - 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone -event 

m=video RTP/AVP 98 99 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



23. SIP re-INVITE request (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP re-INVITE request to the SCC AS. 

24. SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) - see example in table A.7.3- 
24 

The SCC AS updates the old call leg based on the SIP re-INVITE request and sends the SIP 200 (OK) response 
to the SIP re-INVITE request to the intermediate IM CN subsystem entities, using the content of the Via header 
that was received in the SIP re-INVITE request (step 23). In this example the SCC AS includes the contents of 
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the Contact header from the received SIP 200 (OK) response. The SIP 200 (OK) response to the SIP re-INVITE 
request contains the SDP answer derived from the SDP answer that the SCC AS previously received from UE-2 
(Step 14). 

Table A.7.3-24: SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK345b32 . 2 , 
SIP/2 . 0/UDP pcscfl .homel .net ;branch=z9hG4bK56 8f 35 .1, 
SIP/2 . 0/UDP [5555 : : aaa : bbb : ccc : eee] : 2468 ; comp=sigcomp;branch=z9hG4bKashdnsl 

Record- Route : <sccas .homel .net; lr>,<sip:scscfl .homel .net; lr>, <sip: pcscfl .homel .net ; lr> 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=64727891 

To: <tel: +1-212- 555-2222 >;tag=774321 

Call -ID: me03a0s0 9a2sdfgjkl4 91777 

Cseq: 101 INVITE 

Supported: lOOrel; precondition 

Contact : < sip:user2_publicl@home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99- 
ad76cc7f c74>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Accept: application/sdp; 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933800 2987933801 IN IP6 5555 :: eee : fff : aaa : bbb 

s = - 

c = IN IP6 5555 : :eee:fff :aaa:bbb 

t = 

m=audio 6544 RTP/AVP 97 96 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone-event 

m=video RTP/AVP 98 99 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 



25. SIP 200 (OK) response (intermediate IM CN subsystem entities to UE-1) 

The intermediate IM CN subsystem entities ftirward the SIP 200 (OK) response to UE-1. 

26. SIP ACK request (UE-1 to intermediate IM CN subsystem entities) 

UE-1 completes the old call leg update with a SIP ACK request sent to the intermediate IM CN subsystem 
entities. 

27. SIP ACK request ( intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the SCC AS. 

A.8 Signalling flows for PS-PS session continuity in 
conjunction with PS-CS session continuity 

A.8.1 Introduction 

The signalling flows for PS-PS access transfer conjunction with PS-CS access transfer demonstrate how a multimedia 
session is tranferred from Source Access Leg to the Target Access Leg. The following signalling flows are included: 

subclause A. 8. 2 shows an example when a multimedia session is transferred from one IP-C/VN to a new IP -CAN 
and the CS bearer respectively ; and 

subclause A. 8. 3 shows an example when a multimedia session is transferred from one IP -CAN and CS bearer to 
a new IP -CAN. 
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A.8.2 PS - PS in conjunction with PS - CS Access Transfer: PS to 
CS 

In this example, SC UE A has an ongoing muhimedia session with remote UE B over IP-CAN#1 before access transfer. 
When SC UE connects to a new IP-CAN#2, it decides to transfer the multimedia session over the new IP-CAN#2 and 
the CS bearer respectively. 
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Figure A.8.2-1 : Signalling flow for PS - PS in conjunction with PS - CS Access Transfer: PS to CS 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 

2. SC UE A has an ongoing multimedia session with remote UE B 

The call has been anchored at the SCC AS which is in the HPLMN of originating SC UE A. The call leg over 
old IP-CAN is identified with "Call-ID= me03a0s09a2sdfgjkl491777", "From tag=64727891", and "To 
tag=77432r'. The UE A and UE B exchange media over the old IP-CAN, which is maintained while the SC UE 
A initiates the handover procedure. 

Table A.8.2-1 shows an example of the SDP offer from SC UE A to remote UE B. 

NOTE 2: To later show how the media is transferred to the new IP -CAN and CS bearer, only the SDP offer is 
shown in the Table A.8.2-1. 

Table A.8.2-1 : SIP INVITE request (SC UE A to intermediate IM CN subsystem entities) 



INVITE tel:+l-237-555-2222 SIP/2.0 

Via: 

Max- Forwards : 

Route : 

P-Asserted- Identity : 

P-Charging-Vector : 

P-Access-Network-Info : 

Privacy: 

From: 

To: 

Call-ID: 

Cseq: 

Supported: 

Require : 

Proxy-Require : 

Security-Verify: 

Contact : 

Allow: 

Accept : 

Content-Type : 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s = 

c=IN IP6 5555 : :aaa:bbb:ccc :ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode- change -period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 2 

m=message 7654 TCP/MSRP 98 

a=accept-types : text/plain 



2. SC UE A connects to a new IP-CAN#2: 

The SC UE A decides to transfer the multimedia session over the new IP-CAN and CS bearer respectively. The 
UE A obtains an IP address that it will use for the signalling and media. It registers with the S-CSCF over the 
new IP -CAN using multiple registrations procedure. Depending on the UE A configuration, the discovery of the 
P-CSCF in the new IP -CAN may be needed. Based on the UE A and new IP-CAN capabilities, the UE A decides 
to use the same codec that was used over the old IP-CAN. The UE A reserves resources (e.g. QoS) in the new 
IP-CAN that will be needed for the signalling and transferred media, prior to sending the initial SIP INVITE 
request. 

3. SIP INVITE request (SC UE A to intermediate IM CN subsystem entities)- see example in table A.8.2-3 



£75/ 



3GPP TS 24.237 version 8.1 .0 Release 8 57 ETSI TS 1 24 237 V8.1 .0 (2009-03) 

The SC UE A sends an initial SIP INVITE request with a STI and a new SDP offer to the UE B that indicates 
that the new call replaces the existing call. The initial SIP INVITE request establishes a dialog for signalling and 
specifies in the SDP a new contact address that will be used for non-realtime media over the new IP -CAN. Upon 
sending the initial SIP INVITE request, the UE A is ready to receive the RTP packets either over the new IP- 
CAN or the old IP -CAN. The RTP packets may arrive over the new IP-CAN prior to the SC UE are receiving 
the SIP 200 (OK) response for the initial SIP INVITE request. 

Table A.8.2-3: SIP INVITE request (UE A to intermediate IM CN subsystem entities) 



INVITE tel:+l-237-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : f f f ] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : sip :pcscf 1 .homel .net : 75 31; Ir ; comp=sigcomp> , <sip:orig@scscf 1 .homel .net ; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: IEEE-802 . lib 

Privacy: none 

From: <sip :userl_publicl®homel .net>; tag=171828 

To: <tel:+l-237-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj 490237 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 

Require: sec -agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321; portl=7531 

Contact : <sip :userl_publicl@homel .net; gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6>; +g. 3gpp. icsi-ref ="urn%3Aurn-7%3gpp- 
service . ims . icsi .mmtel" ; +g. 3gpp. ics= "principal" ; 

Target -Dialog :me0 3a0s0 9a2sdfgjkl4 91777; to-tag=774 321; f rom-tag=64 72 78 91 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Accept: application/sdp; application/3gpp-ims+xml 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : fff 

s = 

t = 

m=audio RTP/AVP 97 96 

c=IN IP6 5555 :: aaa: bbb: ccc :ddd 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode- change -period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 

m=message 7654 TCP/MSRP 98 

c=IN IP6 5555: :aaa:bbb:ccc:fff 

a=accept-types : text/plain 



4. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

5. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 

The SIP INVITE request is forwarded to the SCC AS as the result of the evaluation of iFC. 

6. Remote Leg Update 

The SCC AS identifies the session to be transferred using the STI. The SCC AS performs the Remote Leg 
update by sending the SIP re-INVITE request towards the Remote Leg. 

7. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities)- See example in table A.8.2-7 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID headers from one side of the B2BUA to the other. In this example the SCC AS includes 
the contents of the Contact header from the received SIP INVITE request. The SIP re-INVITE request contains 
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the SDP offer that is identical to the SDP offer that the SCC AS received in the initial SIP INVITE request from 
the UE A (Step 3). 

Table A.8.2-7: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE < sip: user2 publicl@home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74 >; SIP/2 . 
Via: SIP/2. 0/UDP sccas.homel.net; branch=z9hG4bK332b33 . 3 ; 
Max-Forwards: 67 

Route: <scscf 1 .homel .net ; Ir >, <sip : scscf 2 .home2 .net ; lr>, <sip :pcscf 2 . visited2 .net ; lr> 
P-Asserted-Identity : "John Doe" <sip :userl_publicl®homel .net>, <tel : +l-237-555-llll> 
P-Access-Network-Info: IEEE-802 . lib 
Privacy: none 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023 5 51024" 
P-Charging-Function-Addresses : 

From: <sip :userl_publicl@homel .net>; tag=1717777 
To: <tel:+l-237-555-2222>, tag=4321 
Call-ID: dcl4bltl0b3teghmlk5013237 
Cseq: 111 INVITE 
Supported: precondition, lOOrel 

Contact : < sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf 6>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Accept: application/sdp 
Content-Type: application/sdp 
Content-Length: (...) 
v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : f f f 
s=t=0 

m=audio RTP/AVP 97 96c=IN IP6 5555 :: aaa : bbb : ccc : ddd 
b=AS:25 .4 

a=curr:qos local sendrecv 
a=curr:qos remote none 
a=des:qos mandatory local sendrecv 
a=des:qos none remote sendrecv 
a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode- change -period=2 
a=rtpmap:96 telephone -event 
a=maxptime : 20 

m=message 7654 TCP/MSRP 98 
c=IN IP6 5555: :aaa:bbb:ccc:fff 
a=accept-types : text/plain 



8. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B) 

The intermediate IM CN subsystem entities forwards the SIP re-INVITE request to remote UE B. 
9-10: SIP 200 (OK) response (UE B to SCC AS via Intermediate IM CN subsystem entities) 

The UE B generates the SIP 200 (OK) response to the SIP re-INVITE request and forwards it to the SCC AS. 
11-12: SIP ACK request (SCC AS to UE B via Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response and forwai'ds it to the remote UE B. 
13-14: SIP 200 (OK) response (SCC AS to UE A via Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request and forwards it to the SC UE A. 
15-16: SIP ACK request (SC UE A to SCC AS via Intermediate IM CN subsystem entities) 

The SC UE A generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the SCC AS 

17. Media paths between UE A and UE B 

The non-realtime media is using the new IP -CAN while the realtime media path is still over the old IP-CAN. 

18. SETUP message (SC UE A to Interworking entities) 

The SC UE sends the CS SETUP message with the STN as the called party number. 
NOTE 3: STN is a PSI DN used by the UE to request a session transfer towards the SCC AS. 
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19. SIP INVITE request (Interworking entities to Intermediate IM CN subsystem entities) -see example in 
Table A.8.2-19 

Table A.8.2-19: SIP INVITE request (interworking entities to intermediate IM CN subsystem entities) 



INVITE tel:+l-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mscl.homel.net; branch=z9hG4bKnashds7 

Max- Forwards : 70 

Route : <sip : icscf 1 . homel . net : 7531 ; Ir ; comp=sigcomp> 

P-Asserted-Identity: <tel: +l-237-555-llll> 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 

P-Access-Network-Info : 

Privacy: none 

From: <tel: +l-237-555-llll>; tag=171828 

To: <tel:+l-237-555-2222> 

Call -ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Supported: lOOrel, precondition 

Require: sec -agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321; port=7531 

Contact : <sip :mgcf 2 .home2 .net ;gr>; +g. 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Accept: application/sdp, application/3gpp-ims+xml 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

t=0 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode- change -period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 2 



Request-URI: contains the IMRN, as obtained from CS networks signalling. 

SDP: The SDP contains preconfigured set of codecs supported by the MGW. 

Editor" s Note: Details pertaining to ICSI vlaues in the Contact header, P-Preferred-Service header, P-Asserted- 

Service header. Accept header and Accept-Contact header need to be included in the the SIP requests and 
SIP responses of this call flow. 

Editor"s Note: The value that the interworking entities include in the the P-Access-Network-Info header in this 
SIP INVITE needs to be documented in this example. 

20. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

21. SIP INVITE request (Intermediate IM CN subsystem entities to SCC AS) 

22. Remote Leg Update 

The SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the Remote Leg. 

23. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) -see example in table A.8.2- 

23 

The SCC AS acting as a routing B2BUA generates a SIP INVITE request based upon the received SIP INVITE 
request and the information previously stored against this session and routes it towards UE B via the 
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intermediate IM CN subsystem entities. In this example the SCC AS includes the contents of the Contact header 
from the received SIP INVITE request. 

Table A.8.2-23: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE < sip: user2 publicl®home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74 > SIP/2 . 

Via: SIP/2. 0/UDP sccasl . homel . net ;branch=z9hG4bKnas34r5 

Max-Forwards: 67 

Route: <sip : scscfl .homel .net : lr> 

P-Asserted-Identity: <tel: +l-237-555-llll> 

P- Charging- Function-Addresses : ccf = [5555: :b99:c88:d7 7:eSS] ; ccf = [5555 : :a55 :b44 :c33 :d22] ; 
ecf= [5555: : If f : 2ee : 3dd: 4ee] ; ecf= [5555: : 6aa : 7bb : 8cc : 9dd] 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig- 
ioi="type3homel .net" 

P-Access-Network-Info : 

Privacy: none 

From: <tel: +l-237-555-llll>; tag=171828 

To: <tel:+l-237-555-2222>; tag=26545 

Call -ID: Cb0 3a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Supported: lOOrel, precondition 

Require: sec -agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321; port=7531 

Contact : < sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a7S5- 
00a0c91e6bf 6>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Accept: application/sdp, application/3gpp-ims+xml 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : eee 

s = 

c=IN IP6 5555 :: aaa :bbb : ccc : eee 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 2 

m=message TCP/MSRP 98 

a=accept-types : text/plain 



Editor"s Note: The value of the P- Access-Network-Info header that is sent in the SIP re-INVITE request towards 
the called party needs to be documented in this example. 

24. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B) 

Intermediate IM CN subsystem entities forward the SIP re-INVITE request to remote UE B. 

25. SIP 200 (OK) response (UE B to intermediate IM CN subsystem entities) 

Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE B has all resources available, 
it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The 
SDP answer indicates that the resources are available. 

26. SIP 200 (OK) response (intermediate IM CN subsystem entities to SCC AS) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SIP re-INVITE request to 
the SCC AS in the originating network. 

27-28. SIP ACK request (SCC AS to UE B via IM CN subsystem entities) 

The SCC AS generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request 
to the remote UE B. 
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29-30. SIP 200 (OK) response (SCC AS to interworking entities via IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request, and forwards the SIP 200 (OK) 
response to the interworking entities. 

31. ISUP CONNECT message (interworking entities to SC UE A) 

32. ISUP CONNECT Response message (SC UE A to interworking entities) 

33-34. SIP ACK request (interworking entities to SCC AS via IM CN subsystem entities) 

The interworking entities generate the SIP ACK request to the SIP 200 (OK) response, and forward it to the SCC 
AS. 

35-36: SIP BYE request (SCC AS to SC UE A via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the old IP -CAN, by sending a BYE request to the 
UEA. 

37-38. SIP 200 (OK) response (SC UE A to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the BYE request over the old IP -CAN, the SC UE A sends a SIP 200 (OK) response over the old 
IP-CAN to the SCC AS. Subsequently, the SC UE A reUnquishes all resources pertaining to the old IP-CAN. 

39. Media paths between SC UE A and UE B 

Finally, the non-realtime media path is over the new IP-CAN and the realtime media is using the CS bearer. 

A.8.3 PS - PS in conjunction with PS - CS Access Transfer: CS to 
PS 

In this example, SC UE A has an ongoing multimedia session with remote UE B over IP-CAN#1 and CS bearer before 
access transfer. When SC UE connects to a new IP-CAN#2, it decides to transfer all the multimedia session over the 
new IP-CAN#2. 
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1 . SC UE A is on an active multimedia session with UE B. Call is anchored at SCC AS. 



Figure A.8.3-1 : Signalling flow for PS - PS in conjunction with PS - CS Access Transfer: CS to PS 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 
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1. SC UE A has an ongoing multimedia session with remote UE B 

The non realmedia path is over old IP-CAN#1 and the reahime media path is over the CS bearer. The call has 
been anchored at the SCC AS which is in the HPLMN of originating SC UE A. The call leg over old IP-CAN#1 
is identified with "Call-ID= me03a0s09a2sdfgjkl491777", "From tag=64727891", and "To tag=774321". The UE 
A and UE B exchange media over the old IP-CAN, which is maintained while the SC UE A initiates the 
handover procedure. 

2. SC UE A connects to a new IP-CAN#2 

The SC UE A decides to transfer the multimedia session over the new IP-CAN#2. The UE A obtains an IP 
address that it will use for the signalling and media. It registers with the S-CSCF over the new IP-CAN using 
multiple registrations procedure. Depending on the UE A configuration, the discovery of the P-CSCF in the new 
IP-CAN may be needed. Based on the UE A and new IP-CAN capabilities, the UE A decides to use the same 
codec that was used over the old IP-CAN. The UE A reserves resources (e.g. QoS) in the new IP-CAN that will 
be needed for the signalling and transferred media, prior to sending the initial SIP INVITE request. 

3. SIP INVITE request (SC UE A to intermediate IM CN subsystem entities)- see example in table A.8.3-3 

Upon sending the initial SIP INVITE request, the UE A is ready to receive the RTP packets either over the new 
IP-CAN or the old IP -CAN. The RTP packets may arrive over the new IP-CAN prior to the SC UE are receiving 
the SIP 200 (OK) response for the initial SIP INVITE request. 

Table A.8.3-3: SIP INVITE request (UE A to intermediate IM CN subsystem entities) 



INVITE tel:+l-237-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc : f f f ] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 70 

Route : sip ipcscf 1 .homel .net : 7531; lr;comp=sigcomp>, <sip lorigOscscf 1 .homel .net; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: IEEE-802 . lib 

Privacy: none 

From: <sip :userl_publicl®homel .net>; tag=171828 

To: <tel:+l-237-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj 490237 

Cseq: 127 INVITE 

Supported: lOOrel; precondition, gruu, 199 

Require: sec-agree, replaces 

Proxy-Require: sec-agree 

Accept -Contact : * ; +g. 3gpp . icsi-ref="urn%3Aurn-7%3gpp- service . ims . icsi .mmtel" 

P- Preferred- Service : urn: urn- 7 : 3gpp- service . ims .icsi .mmtel 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321; portl=7531 

Contact : <sip :userl_publicl®homel .net ;gr= urn:uuid: f81d4fae-7dec-lld0-a765- 
00a0c91e6bf 6>; +g . 3gpp- icsi-ref ="urn%3Aurn-xxx%3gpp- 
service . ims . icsi .mmtel" ; +g. 3gpp. ics= "principal" ; 

Replaces: me03a0s09a2sdfgjkl491777; to-tag=774321 ; f rom-tag=64727891 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Accept: application/sdp; application/3gpp-ims+xml 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : f f f 

s = 

c = IN IP6 5555 : :aaa:bbb:ccc:fff 

t = 

m=audio 3456 RTP/AVP 97 96a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode- change -period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 20 

m=message 7654 TCP/MSRP 98 

a=accept-types : text/plain 



Request-URI: Contains the static STI. 
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4. Evaluation of initial filter criteria 

The S-CSCF evaluates initial filter criteria for the served SC user and as a result routes the SIP INVITE request 
towards the SCC AS. 

5. SIP INVITE request (intermediate IM CN subsystem entities to SCC AS) 

The SIP INVITE request is forwarded to the SCC AS as the result of the evaluation of iFC. 

6. Remote Leg Update 

The SCC AS identifies the session to be transferred using the STI. The SCC AS performs the Remote Leg 
update by sending the SIP re-INVITE request towards the Remote Leg. 

7. SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities)- See example in table A.8.3-7 

The SCC AS modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, 
To, Cseq and Call-ID headers from one side of the B2BUA to the other. In this example the SCC AS includes 
the contents of the Contact header from the received SIP INVITE request. The SIP re-INVITE request contains 
the SDP offer that is identical to the SDP offer that the SCC AS received in the initial SIP INVITE request from 
the UE A (Step 3). 

Table A.8.2-7: SIP re-INVITE request (SCC AS to intermediate IM CN subsystem entities) 



INVITE sip:User2_publicl@home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74 SIP/2 . 
Via: SIP/2. 0/UDP sccas.homel.net; branch=z9hG4bK332b33 . 3 ; 
Max- Forwards : 67 

Route: <scscf 1 .homel .net ; Ir >, <sip : scscf 2 .home2 .net ; lr>, <sip :pcscf 2 . visited2 .net ; lr> 
P-Asserted-Identity : "John Doe" <sip :userl_publicl@homel .net>, <tel : +l-237-555-llll> 
P-Access-Network-Info: IEEE-802 . lib 
Privacy: none 

P- Charging- Vector : icid-value="AyretyU0dm+SO2IrT5tAFrbHLso=023551024" 
P-Charging-Function-Addresses : 

From: <sip :userl_publicl@homel .net>; tag=569812 
To: <tel:+l-237-555-2222>, tag=4321 
Call -ID: dcl4bltl0b3teghmlk50132 3 7 
Cseq: 111 INVITE 

Contact : <sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91eGbf 6>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : f f f 

s = 

c = IN IP6 5555 : :aaa:bbb:ccc:fff 

t = 

m=audio 3456 RTP/AVPF 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 20 

m=message 7654 TCP/MSRP 98 

a=accept-types : text/plain 



8. SIP re-INVITE request (Intermediate IM CN subsystem entities to UE B) 

The intermediate IM CN subsystem entities forwards the SIP re-INVITE request to remote UE B. 
9-10: SIP 200 (OK) response (UE B to SCC AS via Intermediate IM CN subsystem entities) 

The UE B generates the SIP 200 (OK) response to the SIP re-INVITE request and forwards it to the SCC AS. 
11-12: SIP ACK request (SCC AS to UE B via Intermediate IM CN subsystem entities) 
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The sec AS generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the remote UE B. 
13-14: SIP 200 (OK) response (SCC AS to UE A via Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request and forwards it to the SC UE A. 
15-16: SIP ACK request (SC UE A to SCC AS via Intermediate IM CN subsystem entities) 

The SC UE A generates the SIP ACK request to the SIP 200 (OK) response and forwards it to the SCC AS 

17. Media paths between UE A and UE B 

The multimedia is using the new IP -CAN. Resources used for signalling on the old IP-CAN#1 and CS bearer are 
not released. 

18-19. SIP BYE request (SCC AS to SC UE A via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg- that was using the old IP-CAN#1, by sending a SIP BYE request 
towards the SC UE A. 

20-21. SIP 200 (OK) response (SC UE A to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the SIP BYE request over the old IP-CAN#1, the SC UE A sends a SIP 200 (OK) response over 
the old IP-CAN. Subsequently, the UE-1 relinquishes all resources pertaining to the old IP-CAN. 

22-23. SIP BYE request (SCC AS to interworking entities via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the CS bearer, by sending a BYE request. 
24-25. ISUP Message 

Upon receiving the DISCONNECT request, the SC UE A relinquishes all resources pertaining to the CS bearer. 
26-27. SIP 200 (OK) response (Interworking entities to SCC AS via intermediate IM CN subsystem entities) 
28. Media paths between UE A and UE B 

The multimedia session is using the new IP-CAN#2. 

A.9 Signalling flows for media adding/deleting 
A. 9.1 Introduction 

The signalling flows for media adding/deleting demonstrate how the media of a multimedia session is added or deleted. 
The following signalling flow is included: 

subclause A.9. 2 shows an example when the non-realtime media of a multimedia session over the IP -CAN is 
removed. 

A. 9. 2 Remote End Initiation case - Removing media from split CS 
and PS sessions 

As a precondition the SC UE A has a CS call and IMS multimedia session with the remote end after session transfer in a 
manner that more than one session are presented to UE B as one IMS session by the SCC AS. 
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SC UE A is on an active multimedia session with UE B. Call is anchored at SCC AS. 
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Figure A.9.2-1 : Remote End Initiation case - Removing media from split CS and PS sessions 

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow. 
1. SC UE A has an ongoing multimedia session with remote UE B 

The call has been anchored at the SCC AS which is in the HPLMN of originating SC UE A. 
Table A.9.2-1 shows an example of the SDP offer from SC UE A to remote UE B. 
NOTE 2: To show how the media is removed, only the SDP offer is shown in this example. 
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Table A.9.2-1 : SIP INVITE request (SC UE A to intermediate IM CN subsystem entities) 



INVITE tel:+l-237-555-2222 SIP/2.0 

Via: 

Max- Forwards : 

Route : 

P- Asserted- Identity: 

P-Charging-Vector : 

P-Access-Network-Info : 

Privacy: 

From: 

To: 

Call-ID: 

Cseq: 

Supported: 

Require : 

Proxy-Require : 

Security- Verify: 

Contact : 

Allow: 

Accept : 

Content-Type : 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s = 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=message 7654 TCP/MSRP 98 

a=accept-types : text/plain 



2. SIP re-INVITE request (UE B to intermediate IM CN subsystem entities)- See example in table A.9.2.-2 

The remote UE B decides to remove the non-realtime media from the multimedia session. It uses standard IMS 
procedures to remove one or more PS media from the session. 
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Table A.9.2-2: SIP re-INVITE request (UE B to intermediate IM CN subsystem entities) 



INVITE < sip:userl_publicl®homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-0 0a0c91e6bf 6> SIP/2 . 

Via: SIP/2. 0/UDP sccasl . homel . net ;branch=z9hG4bKnas34r5 

Max-Forwards: S7 

Route: <sip : scscfl .homel .net : lr> 

P-Asserted-Identity: <tel: +l-237-555-2222> 

P- Charging- Function- Addresses : ccf=[5555::b9 9:c88:d7 7:e66]; ccf=[5555::a55 :b44 :c3 3 :d22] ; 
ecf= [5555: : If f : 2ee : 3dd: 4ee] ; ecf= [5555: : 6aa : 7bb : 8cc : 9dd] 

P-Charging-Vector : icid-value="AyretyU0dm+SO2IrT5tAFrbHLso=023551024" ; orig- 
ioi="type3homel .net" 

P-Access-Network-Info : 

Privacy: none 

From: <tel: +1-237-555-2222; gr=hdg7777ad7af IzigSsf 7> ; tag=171828 

To: <tel:+l-237-555-llll> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: lOOrel, precondition 

Require: sec -agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi=87654321; port=7531 

Contact : < sip:user2_publicl®home2 .net ;gr=urn:uuid: 2ad8950e-4 8a5-4a74-8d99- 
ad76cc7f c74>; +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Accept: application/sdp, application/3gpp-ims+xml 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = 

c=IN IP6 5555 :: aaa: bbb: ccc : ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode- change -period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 

m=message TCP/MSRP 98 

a=accept-types : text/plain 



3. SIP re-INVITE request (Intermediate IM CN subsystem entities to SCC AS) 

4-5. SIP 200 (OK) response (SCC AS to UE B via Intermediate IM CN subsystem entities) 

The SCC AS generates the SIP 200 (OK) response to the SIP re-INVITE request and forwards it to the remote 
UEB. 

6-7: SIP ACK request (UE B to SCC AS via Intermediate IM CN subsystem entities) 

The UE B generates the SIP ACK request to the SIP SIP 200 (OK) response and forwards it to the SCC AS. 

8-9: SIP BYE request (SCC AS to SC UE A via intermediate IM CN subsystem entities) 

The SCC AS terminates the replaced call leg, which was using the IP-CAN, by sending a SIP BYE request to the 
UEA. 

10-11. SIP 200 (OK) response (SC UE A to SCC AS via intermediate IM CN subsystem entities) 

Upon receiving the BYE request over the IP -CAN, the SC UE A sends a SIP 200 (OK) response over the IP- 
CAN to the SCC AS. Subsequently, the SC UE A relinquishes all resources pertaining to the IP -CAN. 

12. Media paths between SC UE A and UE B 

Finally, the non-realtime media path over the IP-CAN is removed. 



£75/ 



3GPP TS 24.237 version 8.1.0 Release 8 



69 



ETSI TS 124 237 V8.1.0 (2009-03) 



Annex B (informative): 
Change history 



Change history 


Date 


TSG# 


TSG Doc. 


CR 


Rev 


Subject/Comment 


Old 


New 


2008-05 


CT1#53 


CI -082007 






Skeleton of TS from rapporteur 




0.0.0 


2008-05 


CT1#53 


CI -082008 
CI -082009 






Incorporate agreed P-CRs from CT1#53 


0.0.0 


0.1.0 


2008-05 


Email 
Review 








Format update 


0.1.0 


0.1.1 


2008-06 


CT1#54 


CI -082394 






Pseudo-CR on Introduction for signalling flows 


0.1.1 


0.2.0 


2008-06 


CT1#54 


CI -082666 






Application level handover 


0.1.1 


0.2.0 


2008-06 


CT1#54 


CI -082667 






Role of UE in registration 


0.1.1 


0.2.0 


2008-06 


CT1#54 


CI -082668 






Role of UE in origination and termination 


0.1.1 


0.2.0 


2008-06 


CT1#54 


CI -082669 






Role of UE in PS-PS session continuity 


0.1.1 


0.2.0 


2008-06 


CT1#54 


CI -082671 






Pseudo-CR on Cleanup of TS 24.237 


0.1.1 


0.2.0 


2008-06 


CT1#54 


CI -082672 






Pseudo-CR on Roles for registration in IMS 


0.1.1 


0.2.0 


2008-06 


CT1#54 


CI -082766 






Pseudo-CR on Signalling flows for CS call origination 


0.1.1 


0.2.0 


2008-06 


CT1#54 


CI -082767 






Pseudo-CR on Signalling flows for CS call termination 


0.1.1 


0.2.0 


2008-08 


CT1#55 


CI -083376 






Clarifications usage of CS and ICS within IMS SC 


0.2.0 


0.3.0 


2008-08 


CT1#55 


CI -083377 






Functional Entities 


0.2.0 


0.3.0 


2008-08 


CT1#55 


CI -083378 






Signalling flows for registration 


0.2.0 


0.3.0 


2008-08 


CT1#55 


CI -083379 






sec AS procedures for PS-PS session continuity 


0.2.0 


0.3.0 


2008-08 


CT1#55 


CI -083380 






SC UE procedures for PS-PS session continuity 


0.2.0 


0.3.0 


2008-08 


CT1#55 


CI -083382 






Signalling flow for Media adding/deleting 


0.2.0 


0.3.0 


2008-10 


CT1#55bis 


CI -083783 






PS-PS Access transfer with full media transfer 


1.0.0 


1.1.0 


2008-10 


CT1#55bis 


CI -083903 






Editorial Cleanup 


1.0.0 


1.1.0 


2008-10 


CT1#55bis 


CI -084260 






network capabilities and URI assignments for IMS SC 


1.0.0 


1.1.0 


2008-10 


CT1#55bis 


CI -084261 






Procedures for IMS SC call origination 


1.0.0 


1.1.0 


2008-10 


CT1#55bis 


CI -084262 






Procedures for call termination 


1.0.0 


1.1.0 


2008-10 


CT1#55bis 


CI -084265 






Signalling flow for PS-CS session continuity 


1.0.0 


1.1.0 


2008-10 


CT1#55bis 


CI -084266 






Signalling flow for PS-PS session continuity in conjunction with 
PS- CS session continuity 


1.0.0 


1.1.0 


2008-10 


CT1#55bis 


CI -084268 






Clarification of signalling flow for call termination 


1.0.0 


1.1.0 


2008-10 


CT1#55bis 


CI -084269 






Clarification of signalling flow for call origination 


1.0.0 


1.1.0 


2008-10 


CT1#55bis 


CI -084433 






Signalling Flows for Multiple Registrations 


1.0.0 


1.1.0 


2008-10 


CT1#55bis 


CI -084447 






Procedures for PS-PS session transfer in conjunction with PS- 
CS session transfer 


1.0.0 


1.1.0 


2008-10 


CT1#55bis 


CI -084448 






Procedures for adding/removing media 


1.0.0 


1.1.0 


2008-10 


CT1#55bis 


CI -084449 






Call flow for PS-PS partial media transfer 


1.0.0 


1.1.0 


2008-10 


CT1#55bis 


CI -084506 






Procedures for PS-CS session transfer 


1.0.0 


1.1.0 


2008-10 


CT1#55bis 








Change the Keywords to: IMS, Multimedia Session, and Session 
Continuity. 


1.0.0 


1.1.0 


2008-10 


Email 
Review 








Editorial Cleanup 


1.1.0 


1.1.1 


2008-11 


CT1#56 


CI -084798 






Removal of Editor"s Note 


1.1.1 


1.2.0 


2008-11 


CT1#56 


CI -084866 






cleanup for PS-PS session transfer procedures 


1.1.1 


1.2.0 


2008-11 


CT1#56 


CI -085085 






Correction: No usage of CS indication in non-ICS case 


1.1.1 


1.2.0 


2008-11 


CT1#56 


CI -085242 






Scope of signalling flows 


1.1.1 


1.2.0 


2008-11 


CT1#56 


CI -085243 






Cleanup of call origination signalling flows 


1.1.1 


1.2.0 


2008-11 


CT1#56 


CI -085244 






Cleanup of call termination signalling flows 


1.1.1 


1.2.0 


2008-11 


CT1#56 


CI -085245 






Signalling flows for PS to CS session transfer 


1.1.1 


1.2.0 


2008-11 


CT1#56 


CI -085246 






Signalling flows for PS-i-CS to PS session transfer 


1.1.1 


1.2.0 


2008-11 


CT1#56 


CI -085247 






Clean up of SCC Registration information 


1.1.1 


1.2.0 


2008-11 


CT1#56 


CI -085251 






cleanups to PS-PS in conjunction with PS-CS session transfer 
procedures 


1.1.1 


1.2.0 


2008-11 


CT1#56 


CI -085252 






cleanups for media adding/removing procedures 


1.1.1 


1.2.0 


2008-11 


CT1#56 


CI -085449 






PS-CS session transfer procedures 


1.1.1 


1.2.0 


2008-11 


CT1#56 


CI -085464 






SR-VCC 


1.1.1 


1.2.0 


2008-11 


CT1#56 


CI -085481 






PS-PS full session transfer using Target-Dialog header 


1.1.1 


1.2.0 


2008-11 










Version 2.0.0 created for presentation to CT#42 for approval 


1.2.0 


2.0.0 


2008-12 


CT#42 








Version 8.0.0 created after approval in CT#42 


2.0.0 


8.0.0 


2009-03 


CT#43 


CP-090147 


000 
2 


3 


Cleanup to TS 24.237 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090147 


000 
3 


1 


Remove void introduction subclauses 


8.0.0 


8.1.0 



£75/ 



3GPP TS 24.237 version 8.1.0 Release 8 



70 



ETSI TS 124 237 V8.1.0 (2009-03) 



2009-03 


CT#43 


CP-090147 


000 
4 


2 


UE procedures for operator policy support 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090147 


000 
5 


1 


Flows for originating and and terminating session in session 
comtinuity 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090147 


000 
9 


1 


Correction SR-VCC procedures 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090147 


001 



1 


Correction to flows for session continuity 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090147 


001 
1 


2 


Completion of IMRN functionality 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090147 


001 
2 


1 


sec AS Transparently passing Contact To and From headers 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090147 


001 
3 


3 


Conveying ICS registration information using 3rd party 
Registration and GRUU/ICSI/IARI corrections 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090147 


001 
4 


2 


UseofGRUUbySCUE 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090147 


001 
5 


2 


Modification for the SCC AS procedure for CS to PS session 
transfer 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090147 


001 
8 


2 


Definitions of Dynamic and Static STI 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090147 


001 
9 


2 


Miscellaneous corrections to session continuity procedures 


8.0.0 


8.1.0 


2009-03 


CT#43 


CP-090147 


002 



2 


SCC -Correlation 


8.0.0 


8.1.0 



£75/ 



3GPP TS 24.237 version 8.1.0 Release 8 



71 



ETSI TS 124 237 V8.1.0 (2009-03) 



History 



Document history 


V8.0.0 


January 2009 


Publication 


V8.1.0 


March 2009 


Publication 





















£75/ 



